• Job: GUI Layout Editor Application
    114 replies, posted
[QUOTE=garry;19473624]I really don't think it would. I could code it myself in a couple of weeks.[/QUOTE] Sept you really don't have the time for that. I think that the best idea would be to release what you have and hope someone will take up the offer. Once they've finished you pay them or whatever.
I think the best solution would be to find someone that knows how to program and pay them to do it over the course of a month or two
[QUOTE=garry;19473716]I think the best solution would be to find someone that knows how to program and pay them to do it over the course of a month or two[/QUOTE] I dunno. IMO I'm pretty sure more people would be inclined to even think about doing it if they knew exactly what they were getting into. But hey, that's just my honest opinion.
I would recommend looking some place like SA where there is a wider range of professional programmers.
[QUOTE=Hibame;19473979]I would recommend looking some place like SA where there is a wider range of professional programmers.[/QUOTE] Just watch out for Avenging Dentist. :v:
People, you don't need the GUI itself to produce a layout editor. That's the whole point of garry mentioning .NET or something of the sort. That's also why I mentioned Qt Designer, but apparently garry doesn't want an external tool. garry, you really are asking the wrong people here :v: [editline]07:45PM[/editline] [QUOTE=databee;19473153]Why make a whole UI lib then use some other premade designer?[/QUOTE] Why make a whole 3D graphics engine and then use some other premade modeling package? :downs:
[QUOTE=nullsquared;19475011]People, you don't need the GUI itself to produce a layout editor. That's the whole point of garry mentioning .NET or something of the sort. That's also why I mentioned Qt Designer, but apparently garry doesn't want an external tool. garry, you really are asking the wrong people here :v: [editline]07:45PM[/editline] Why make a whole 3D graphics engine and then use some other premade modeling package? :downs:[/QUOTE] One extreme to another. Unless you're on about model formats then most people would choose to make their own. [editline]12:50AM[/editline] layzee
[QUOTE=nullsquared;19475011]Why make a whole 3D graphics engine and then use some other premade modeling package? :downs:[/QUOTE] Modelling software does not properly render in realtime, as a graphics engine does. especially one for a game.
[QUOTE=Chandler;19475599]Modelling software does not properly render in realtime, as a graphics engine does. especially one for a game.[/QUOTE] GUI editing software does not make a real-time usable GUI, as an actual GUI lib does. Especially one for a game.
-snip- Ignore me!
Personally I think code generation for things like this is the worst way to do it. Gives me the shits messing around with external tools to build another definition of a layout when you already have a perfectly good one. Much nicer to have the layout defined in some format and loaded at runtime.
[QUOTE=blankthemuffin;19477805]Personally I think code generation for things like this is the worst way to do it. Gives me the shits messing around with external tools to build another definition of a layout when you already have a perfectly good one. Much nicer to have the layout defined in some format and loaded at runtime.[/QUOTE] That may work for actual gui applications, however, garry's focus is on games, where it just won't do to have everything changeable at runtime. Some things need to be set in stone.
It won't do to have everything changeable? Do not understand what you're getting at here. [b]Edit:[/b] Ok right I see. Here is a pro-con list. Runtime loaded. Pros: [LIST] [*]Don't have to recompile application to see changes in app. [*]If you leave the layout files in the app as plain text you allow people to modify the UI layout as they see fit. [*]If you don't want them editing the layout files for whatever reason you can serialise the loaded structures into a binary form. [/LIST] Cons: [LIST] [*]Potential to be slower, but if done right there would be no noticeable performance hit. [/LIST] Code generated: Pros: [LIST] [*]Intellisense? [*]Potentially slightly faster. [/LIST] Cons: [LIST] [*]Have to generate code with external tool. [*]Have to re-compile app to see changes. [*]Block modding for no real gain. [/LIST]
[QUOTE=blankthemuffin;19478041]It won't do to have everything changeable? Do not understand what you're getting at here. [b]Edit:[/b] Ok right I see. Here is a pro-con list. Runtime loaded. Pros: [LIST] [*]Don't have to recompile application to see changes in app. [*]If you leave the layout files in the app as plain text you allow people to modify the UI layout as they see fit. [*]If you don't want them editing the layout files for whatever reason you can serialise the loaded structures into a binary form. [/LIST] Cons: [LIST] [*]Potential to be slower, but if done right there would be no noticeable performance hit. [/LIST] Code generated: Pros: [LIST] [*]Intellisense? [*]Potentially slightly faster. [/LIST] Cons: [LIST] [*]Have to generate code with external tool. [*]Have to re-compile app to see changes. [*]Block modding for no real gain. [/LIST][/QUOTE] Could be done similarly to VGUI in Source where you can have res files which have the layout in it, which is also entirely optional if you want everything in code.
[QUOTE=blankthemuffin;19478041]It won't do to have everything changeable? Do not understand what you're getting at here. [b]Edit:[/b] Ok right I see. Here is a pro-con list. Runtime loaded. Pros: [LIST] [*]Don't have to recompile application to see changes in app. [*]If you leave the layout files in the app as plain text you allow people to modify the UI layout as they see fit. [*]If you don't want them editing the layout files for whatever reason you can serialise the loaded structures into a binary form. [/LIST] Cons: [LIST] [*]Potential to be slower, but if done right there would be no noticeable performance hit. [/LIST] Code generated: Pros: [LIST] [*]Intellisense? [*]Potentially slightly faster. [/LIST] Cons: [LIST] [*]Have to generate code with external tool. [*]Have to re-compile app to see changes. [*]Block modding for no real gain. [/LIST][/QUOTE] Having it loaded at runtime robs you off the capability to implement its methods in a particularly C++ way. I'm sorry you couldn't find someone garry, I kinda expected you to get lots of offers. Maybe it's because you told people you probably won't make the game modable, sensitive bunch :v: It actually sounds like a fun project, I'd do it for free if I felt my C++ was up for it.
I would offer to do it, but I'm away from home at the moment so I wouldn't be able to start it within a reasonable timeframe.
The way I would go about doing this is setting up the Editor UI using WinAPI or .Forms. Then Place a DirectX or OpenGL interface into the "Workspace" then use the Workspace to Manipulate GWEN, using the .Forms to Change properties, and whatnot. Mock-Up: [URL="http://img684.imageshack.us/i/gwentkmockup.png/"][IMG]http://img684.imageshack.us/img684/7658/gwentkmockup.png[/IMG][/URL]
-snip?-
[QUOTE=blankthemuffin;19478041]It won't do to have everything changeable? Do not understand what you're getting at here. [b]Edit:[/b] Ok right I see. Here is a pro-con list. Runtime loaded. Pros: [LIST] [*]Don't have to recompile application to see changes in app. [*]If you leave the layout files in the app as plain text you allow people to modify the UI layout as they see fit. [*]If you don't want them editing the layout files for whatever reason you can serialise the loaded structures into a binary form. [/LIST] Cons: [LIST] [*]Potential to be slower, but if done right there would be no noticeable performance hit. [/LIST] Code generated: Pros: [LIST] [*]Intellisense? [*]Potentially slightly faster. [/LIST] Cons: [LIST] [*]Have to generate code with external tool. [*]Have to re-compile app to see changes. [*]Block modding for no real gain. [/LIST][/QUOTE] I don't see the big deal in having an external tool generating code. I mean that is why there are pre-build/pre-link/post-build events. I personally think Qt did a good job at this. Now if only they didn't have that god awful text connecting.
Besides how annoying it is, you're duplicating work. In order to make a GUI editor, you need to be able to manipulate the GUI in real-time via some method. Then you need to be able to dump and load that from your format of choice. Now why would you implement all this, then go and write a code generation app that does exactly what you've just done? In return for a bundle of extra work you get the benefits of an extra compile step, having to recompile to see changes, a buggy code generator and you block modding. It just does not make sense.
[QUOTE=blankthemuffin;19483785]Besides how annoying it is, you're duplicating work. In order to make a GUI editor, you need to be able to manipulate the GUI in real-time via some method. Then you need to be able to dump and load that from your format of choice. Now why would you implement all this, then go and write a code generation app that does exactly what you've just done? In return for a bundle of extra work you get the benefits of an extra compile step, having to recompile to see changes, a buggy code generator and you block modding. It just does not make sense.[/QUOTE] Personally I think SteveUk put it perfectly. I personally would fucking hate a gui library that is limited to only this. If it was a feature I wouldn't complain but I am not going to be using that feature.
[QUOTE=high;19483913]Personally I think SteveUk put it perfectly. I personally would fucking hate a gui library that is limited to only this. If it was a feature I wouldn't complain but I am not going to be using that feature.[/QUOTE] When did I ever suggest this would be the only way to create a GUI? You'd have to go and remove the entire existing API to even do that. I'm saying code generation by an external tool as the only way to do layout automatically is absolutely retarded because all you're doing is duplicating work and making everything harder for yourself.
No, you're making everything EASIER for yourself.
When you make GUI Editor that generates code for you, how are you duplicating work?
[QUOTE=blankthemuffin;19483969]When did I ever suggest this would be the only way to create a GUI? You'd have to go and remove the entire existing API to even do that. I'm saying code generation by an external tool as the only way to do layout automatically is absolutely retarded because all you're doing is duplicating work and making everything harder for yourself.[/QUOTE] Have you ever used something like Qt? It isn't freaking rocket science.
On a less argumentive note, GWEN looks awesome. I've been looking for a lightweight, reliable GUI library for a long time.
Are you reading what I'm writing? It isn't exactly rocket science. I'll describe the two processes in detail. First of all code generation. In our editor we create a project, fill it out, and save it. This creates a serialised version of the layout which the editor uses for saving/loading. Then we hit a magic compile button and our layout file is magically transformed into a C++ header and a C++ source file. We open our ide, import these two new edited files and derive from the class they contain. We fill out our event handlers and hit compile again. We test our app, finding that we want to move a button. We open our editor, move the button, save the layout file, hit compile, the code is generated and we build our application again (hopefully the last few steps were all part of a build process already setup in the IDE of choice. Note especially the duplicated work between the save system in the editor and the code generator. Also note the extra build steps, and in fact the requirement of a build at all. Now let's describe the same process with a dynamic system. In our editor we create a project, fill it out and save it, this goes straight into the resources of the application as the format used for save/load in the editor is the same as the format used by the application. We open our IDE, we derive from a generic base class and assign signal handlers using the names set out in the editor. We hit compile. We find we want to move a button. We open our editor, move the button and save the file. Then we re-run our application. Note the greatly simplified use case, note the lack of code duplication across the save/load system. Really I don't see how there is any competition at all. For some real world cases. GTK+ used to use code generation but switched to a dynamic system such as I describe called GTKBuilder. Clutter uses json to describe layout. WPF uses XAML for layout.
You need to try Qt + Qt visual studio addin :P.
Different strokes for different folks. I'd rather have my shit in the engine than load and parse external files at runtime.
-snip-
Sorry, you need to Log In to post a reply to this thread.