Allegro.cc - Online Community

Allegro.cc Forums » Off-Topic Ordeals » Living the dream

Credits go to bamccaig, Derezo, Felix-The-Ghost, james_lohr, jmasterx, Mark Oates, MiquelFire, Onewing, Polybios, and relpatseht for helping out!
This thread is locked; no one can reply to it. rss feed Print
 1   2 
Living the dream
Mark Oates
Member #1,146
March 2001
avatar

Why should I use GitHub over something else like BitBucket?

To be honest, the reason you should use GitHub is because it's where everybody is these days. Any developer worth their salt will be able to follow your code in BitBucket, but you're asking them to come to you, and that's where the problem lies. Being on GitHub will allow the vast majority of developers to immediately be able to know how to access and navigate through your repo, without any extra effort to learn or use an unfamiliar interface.

Also, you'll likely find a lot of employers who are hosting their team collaboration (and even build tools) through GitHub. If they see you are already familiar and using that platform, then that means less $ and time they have to spend training you on a new platform.

Quote:

Also, Oates, did you see my question above? I was wondering about how you bind your library functions to scripts? Are you using Lua? Or something else? How did you accomplish scripting in your library?

... will answer that later when I have some more time.

--
Visit CLUBCATT.com for cat shirts, cat mugs, puzzles, art and more <-- coupon code ALLEGRO4LIFE at checkout and get $3 off any order of 3 or more items!

AllegroFlareAllegroFlare DocsAllegroFlare GitHub

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Personally, I find BitBucket to have a much cleaner and more professional looking interface. The main menu is obviously located on the left, with convenient links to everything you could want. The git repo address is on the top right, the readme shows up right beneath the project, and everything seems logically placed. You can access downloads, commits, and source. You can easily fork or clone. It just seems so much nicer than GitHub to me.

Also, you simply must tell me how you achieved your Scriptable class. I'm gonna look at the source now. You should put the link to Allegro Flare in your sig so I don't have to keep searching for it.
EDIT

... will answer that later when I have some more time.

Ah yes, okay. Looking forward to it.

Derezo
Member #1,666
April 2001
avatar

Man, that looks like a pretty complex setup.

The wiki may even be out dated -- expect to spend about 1 week before you actually have your working Allegro 5 EAGLE Demo APK in hand ;)

Just go with ubuntu if you're unsure of a distro. Xubuntu if you're low on resources or want to lead a simpler life. It may take a week of frustration before everything clicks, but once you get it you'll understand and be able to do it more easily the next time, or even give instruction for others.

This is really more of an learning exercise at this point, it's a lot of work at first until you get your bearings and understand the components you're working with. Android really has a GUI API of it's own which is the common choice, although there would always be a place for EAGLE in a cross-platform with the same code base circumstance.

"He who controls the stuffing controls the Universe"

Felix-The-Ghost
Member #9,729
April 2008
avatar

...TL;DR.

One thing that would help us all is submitting screenshots as the Image of the Day so we have a new one :3

==========================
<--- The ghost with the most!
---------------------------
[Website] [Youtube]

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

There seems to be a certain dissatisfaction with my website. That's strange, because the feedback I got when I released it was fairly positive.

So tell me, what do you look for in a website? What features and topics and looks are desirable to you guys personally? What do you think I could do to improve my website?

Felix-The-Ghost
Member #9,729
April 2008
avatar

Here is a page from my website (which I really need to update)

You can see there is a lot of color/images, and I think it is important to establish a natural order and flow of information. There is a lot of information to take in when someone visits your site. See how I made different pages on my site? It's easy to find what you are looking for at a glance.

==========================
<--- The ghost with the most!
---------------------------
[Website] [Youtube]

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

@Felix
Your website has a nice clean look to it. I like the way it is organized too. Yet each page retains common themes and background. There's really only one thing there, the skin editor, but that doesn't seem to detract from anything. And you manage to keep all the content on a page limited to less than several screens worth of vertical space. I hate pages that scroll forever. It makes it hard to find things. I like your design, it's colorful, and looks good.

EDIT
@All you html gurus out there :
Is there a way to make a sort of "html object" and re-use it? So I only have to put a single object in each of my pages but it will have common elements? Like a navigation bar that is the same in every page it is in? Can I "plug in" certain html elements? Do I need to use javascript for this?

Felix-The-Ghost
Member #9,729
April 2008
avatar

I tried to post from mobile but it was a disaster. Fortunately when I got on my desktop allegro.cc remembered the text I had typed (even though mobile screwed most of it up)

--

Quote:

You mean like including a common header file in all your source files? When I was building my site (years ago), I had the same question.

I think the best route (I never tried it, I'm not sure if the Allegro server supports server scripting for member sites) is SSI. It includes the content on the server's side before the client sees it, this way you don't have to worry about the client's browser supporting scripting on their end.

Tutorial from htmlgoodies

Let me know if it works for you. I'm curious now if it ever was enabled for member sites.

...and seriously, please, somebody change the Image of the Day already :P

==========================
<--- The ghost with the most!
---------------------------
[Website] [Youtube]

bamccaig
Member #7,536
July 2006
avatar

Mr. Lohr strikes me as being not very friendly and I can't imagine having to serve underneath him is much fun. I doubt his subordinates would speak highly of him unless he's very good at the technical side of things, which would probably make up for his abrasive human interface. He does seem to be more skilled in the technical realm, but that's based on subjective observations over text communication. I do think that he could benefit from developing better human interfaces. Or maybe he's just a dickface. I don't know.

I would agree that "EAGLE" is probably not a practical dream at this point in time. The vast, vast majority of GUI programmers do not want or need extreme customization. They need to be able to write and maintain featureful GUIs in as few lines of code as possible. Customization is certainly desirable, but you never want to need to customize a GUI. You ideally want it to already support all of your needs out of the box. If you need to start developing your own GUI then you're going to start banging your head off your desk because its API will necessarily not be 100% compatible with your own.

This is why I abhor GUIs. They're necessarily complex and wasteful and a massive burden and expense to develop and maintain. I've never encountered a truly easy/simple GUI system that is also powerful, and your descriptions of EAGLE make it sound like a nightmare for an application developer trying to get work done. Of course, in theory, if suitable widgets already exist maybe it won't be bad, but you will need high-level APIs for the business programmer to find any use in your GUI. Low-level APIs might be necessary for game programmers, but most big game studios will use a more popular, robust solution or roll their own. Your solution will not bring in sustainable income unless you can figure out a target market of users that can either attain money or pleasure from it themselves (i.e., people won't give you money just to please you). Free software (i.e., libre) does not mean gratis, albeit, you will likely have trouble selling the second license. The typical approach is to instead sell support services (i.e., configuration, diagnosis, or customization).

That said, EAGLE will likely be a useful portfolio piece to demonstrate to prospective employers when you submit to the job market. And in time you may well make a killer GUI out of it... That said, the Windows ecosystem is unlikely to embrace EAGLE so you had better develop your Linux and/or OS X skills to expand your market. And if you can figure out a suitable mobile interface that would greatly benefit you as well since that's likely a large part of the computing future.

The majority of GUI developers don't want to have to customize shit. If I'm stuck developing a GUI I want to be able to define it with a minimal set of markup or code and have it mostly just work. Scripting is a useful way to hook into event handling too, but that adds an additional burden onto the API developer, and additional debugging complexities onto the GUI developer.

In terms of "HTML"-reuse, there are two typical answers: server-side programming (i.e., an application server such as PHP, ASP, CGI, WSGI or other similar technologies) or XSLT (which doesn't have perfect browser support, sadly).

The former lets you accomplish anything dynamically by running a program every time a user navigates to a page in your Web site. The program generates a response based on the request parameters. The response can be anything, but naturally, code-reuse is easy when you have full programming capabilities.

The latter is like an XML-based template system. Non-shit (i.e., non-Microsoft) browsers have supported the technology for years. I'm uncertain of Microsoft's latest status since they're trying to pretend to play ball now, but last I checked they didn't support it. In practice, it's not very often used unprocessed on the Web (perhaps for that reason).

My Web site is currently based on an XSLT template partially as a learning experience and partially because I didn't want to use PHP and was unfamiliar with better free software server-side application options at the time. Initially my site had both the raw XSLT/XML plus rendered HTML for browsers that needed it. I have since become lazy and rendered the XSLT/XML into static HTML documents server-side to make sure everything worked. My professional career has me focused on the Windows/.NET ecosystem so I'm limited in time and ambition to expand outside of it in my drinking hours. In any case, aside from lacking dynamic date formatting, I was pretty satisfied with the output from my XSLT template. And even that could probably be improved upon. I don't anticipate that it will help much, but ... this is my "stylesheet" and this is an example content document (the contents are years outdated and I haven't even tried the XSLT conversion in a while; it seems Firefox isn't transforming it, but perhaps that's just cookie/script blocking). View source on the document if what you see isn't source code (which is preferred). It was a first and clumsy attempt at using XSLT for real, but based on the namespace I imagined it appears I developed it approximately 6 years ago. I'm old and it's sad.

The point: HTML/CSS/JavaScript reuse is all quite easy. It just depends on at what stage you want for custom code/programming to take place. Similarly, there are alternative high-level styling and scripting languages that can be "compiled" into CSS or JavaScript. Again, whether dynamically or statically is up to you. Mind you, that's over a decade of Web development speaking so I imagine it's overwhelming for you. And that's normal. There is in fact a lot involved... You won't come up with perfect answer in one iteration. You should attempt to address Web site concerns incrementally. Pick a small, simple goal and try to solve that. If you fail break it up even further into a smaller, simpler goal or move on. Rinse and repeat until you're satisfied.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

bamccaig said:

The vast, vast majority of GUI programmers do not want or need extreme customization. They need to be able to write and maintain featureful GUIs in as few lines of code as possible. Customization is certainly desirable, but you never want to need to customize a GUI. You ideally want it to already support all of your needs out of the box. If you need to start developing your own GUI then you're going to start banging your head off your desk because its API will necessarily not be 100% compatible with your own.

Most GUI users necessarily won't be perfectly happy with the way a GUI looks right out of the box, unless you do something like native widgets like wX does, so naturally they'll want to customize the styling to at least some degree, and my gui easily allows for that. Native widget support is not easily accomplished, and others have already done that. That's not what I'm going for. One day I may make native widget look and feel styles, but that's not real high on my list of things to do.

bamccaig said:

This is why I abhor GUIs. They're necessarily complex and wasteful and a massive burden and expense to develop and maintain. I've never encountered a truly easy/simple GUI system that is also powerful, and your descriptions of EAGLE make it sound like a nightmare for an application developer trying to get work done. Of course, in theory, if suitable widgets already exist maybe it won't be bad, but you will need high-level APIs for the business programmer to find any use in your GUI. Low-level APIs might be necessary for game programmers, but most big game studios will use a more popular, robust solution or roll their own.

We all know you hate GUI's bam. But the vast majority of people prefer GUI's to command line interfaces. People like point and click. It's easy. All the work has already been done for you. People are lazy. They don't want what they are doing to take more effort than necessary. That necessarily shifts the burden of work onto GUI and application designers.

I've only ever described my GUI as simple, customizable, and extensible. What part of that makes it sound like it is difficult to get work done with it? The code requirements are pretty simple. It's one line each to create an EagleSystem, an EagleGraphicsContext, and a WidgetHandler. It's one line for each widget you want. It's one line to add all your widgets to the gui. One line for every layout you want to use. Some widgets may necessarily need more information for start up, but that's not hard either. Then once you have your GUI setup you simply run an event loop :

#SelectExpand
1 sys->GetSystemTimer()->Start(); 2 3 do { 4 if (redraw) { 5 gui.Display(win,0,0); 6 win->FlipDisplay(); 7 redraw = false; 8 } 9 10 do { 11 EagleEvent ee; 12 ee = sys->WaitForSystemEventAndUpdateState(); 13 14 if (ee.type == EAGLE_EVENT_DISPLAY_RESIZE) { 15 win->AcknowledgeResize(); 16 gui.SetWidgetArea(0 , 0 , win->Width() , win->Height()); 17 } 18 19 gui.HandleEvent(ee); 20 21 while (gui.HasMessages()) { 22 WidgetMsg wmsg = gui.TakeNextMessage(); 23 EagleLog() << wmsg << endl; 24 if (wmsg.From() == &b1) { 25 /// Deal with message from widget b1 here 26 } 27 } 28 if (ee.type == EAGLE_EVENT_DISPLAY_CLOSE) { 29 quit = true; 30 } 31 if (ee.type == EAGLE_EVENT_KEY_DOWN && ee.keyboard.keycode == EAGLE_KEY_ESCAPE) { 32 quit = true; 33 } 34 if (ee.type == EAGLE_EVENT_TIMER) { 35 redraw = true; 36 } 37 38 } while(!sys->UpToDate()); 39 } while (!quit);

It's very much modeled after Allegro's event loop. There are basically three major functions for each widget - Display, HandleEvent, and Update. These three functions provide for drawing, input, and animation. They can easily be extended to game objects. Have an object in your game? Make a widget for it! Tell it how to draw, what input it receives, and what to do when time passes, and it will run itself!

There's very much more to EAGLE than a GUI. It's a full abstraction of events, drawing and input over the top of Allegro (or SDL, or SFML, or whatever you want). Use your favorite graphics library with it with ease due to the use of system and graphics drivers.

I think what I really need is to come up with a set of tutorials on using EAGLE. That way everyone could easily see what it can do. I'm still working on getting the doxygen documentation right, but it's coming along.

bamccaig said:

That said, EAGLE will likely be a useful portfolio piece to demonstrate to prospective employers when you submit to the job market. And in time you may well make a killer GUI out of it... That said, the Windows ecosystem is unlikely to embrace EAGLE so you had better develop your Linux and/or OS X skills to expand your market. And if you can figure out a suitable mobile interface that would greatly benefit you as well since that's likely a large part of the computing future.

That's what I would like it to be. I can do some dev work on Linux, but I don't have access to any OSX hardware atm. Once I get Linux up and running, I will test things out on Android.

bamccaig said:

Bunch of stuff about web dev

Thanks, I'll look into it.

I appreciate the feedback everyone!!! Cookies!

Additional comments are still more than welcome! ;)

Felix-The-Ghost
Member #9,729
April 2008
avatar

Just realized your site, like mine, is an allegro.cc provided site. If SSI works for you let me know :)

Otherwise we both will probably want to host our own sites soon.

==========================
<--- The ghost with the most!
---------------------------
[Website] [Youtube]

jmasterx
Member #11,410
October 2009

IMO a gui api/sdk that is truly useful does not just lets you make your interfaces and bind them quickly to events and functions in native code, but comes with tools that can allow non-programmers like artists to customize the whole look and feel. Or also allow the creation of custom widgets with ease (how quickly can I make a messagebox from frames, buttons, checkboxes and Labels and how easy is it to bind to events of those child Widgets?)

How easily can I do stupid things like password fields and a textbox that only accepts hex or text defined by a regex?

The output of these tools is either xml, or generated code, etc.
Ideally, these tools integrate well with the ide your target audience will dev with.

With a few clicks, a non programmer should be able to make a scrollbar that becomes semi transparent and turns the bottom thumb green when the top thumb is double clicked.

WPF is not a bad example of this sort of thing. Integrating blend and VS. MVVM is also quite nice. Like any GUI system it has its pitfalls but most common things are fairly easy to achieve (but styles are a pain).

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

jmasterx said:

IMO a gui api/sdk that is truly useful does not just lets you make your interfaces and bind them quickly to events and functions in native code, but comes with tools that can allow non-programmers like artists to customize the whole look and feel. Or also allow the creation of custom widgets with ease (how quickly can I make a messagebox from frames, buttons, checkboxes and Labels and how easy is it to bind to events of those child Widgets?)

I do plan to have a full gui editor as my demo program. Allowing the user to define drawing instructions for a widget would be possible, but it seems like overkill to allow for artists to become programmers, in one sense. Ninepatches and background images are supported, as well as custom background drawing. So it's not like it's hard for artists to do their job, or to interface with the gui designers. Creating custom widgets is super easy. All you need to do is define a new object consisting of your component objects and then hook them together by defining the behavior when they interact. For this purpose you can use messages, event listeners, or callbacks.

jmasterx said:

How easily can I do stupid things like password fields and a textbox that only accepts hex or text defined by a regex?

It wouldn't be too hard to support things like this, with a few minor modifications to existing classes to support validation / character display routines.

jmasterx said:

The output of these tools is either xml, or generated code, etc.
Ideally, these tools integrate well with the ide your target audience will dev with.

XML is ugly. I prefer a simple plain text script. Right now I have a simple text file that describes widgets and guis. It's as simple as writing out the class name and then providing a whitespace separated list of attributes. Similar to xml or html, but without all the ugly bracketification.

Then these gui definition files can be loaded and displayed at runtime. I'm still working on the actual scripting side of the gui though. I would like to be able to connect arbitrary functions to widget messages or events and then execute code. Widgets are all referenced by name, so getting the message to the right widget is not the problem, but the dynamic execution of code is.

What kind of scripting options are there out there? I've heard of LUA but I am not very familiar with its practical use. I've tried Ruby and I like it so far, but what is the best way to dynamically bind functions with script?

jmasterx said:

With a few clicks, a non programmer should be able to make a scrollbar that becomes semi transparent and turns the bottom thumb green when the top thumb is double clicked.

Transparency is no problem, all you have to do is change the color. Alpha blending is supported natively. I'm not sure what you're talking about with the thumbs but that's not hard either.

jmasterx said:

WPF is not a bad example of this sort of thing. Integrating blend and VS. MVVM is also quite nice.

I am not familiar with those, but I can take a look.

jmasterx
Member #11,410
October 2009

Transparency is no problem, all you have to do is change the color. Alpha blending is supported natively. I'm not sure what you're talking about with the thumbs but that's not hard either.

I'm sure those functions are supported by your api. I do not doubt that at all. I'm saying how easy is it for a non-programmer to get that effect for the scrollbars.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Oh, okay. Well, in the GUI editor I plan on making, there will be the option to customize the color for each widget and for each widget color. It will be as simple as picking a color, and it will become transparent. The editor will save code either as C++ code, or as gui script, depending on what you want.

As far as creating interactive elements goes, I've got some work to do on that. I'm looking for a good scripting solution. Do you have any input on how to properly integrate scripting into my gui?

 1   2 


Go to: