Re: [pygame] New GUI
Patrick Mullen wrote: For a toolkit that can only be used in pygame, ignoring things like pyopengl, python-ogre, etc, such limited use I don't see as being very marketable. If it was generalized, and pluginable to almost any python program, that starts to have some real value. True - being Pygame specific does greatly limit the market, I hadn't considered that. Thanks for the feedback!
Re: [pygame] New GUI
> Show me a GUI builder that in fact produces clean, non-overloaded code, > that does not break, if I manually change, add or remove stuff and so > effectively eases development. I am not aware of any. If they do not > match these criteria, but I am instead forced to stick with them (like > e.g. VS.NET), they are useless. Gui builders really ought to store the gui structure and then let the coder write all the functionality hooks. Like, oh, I don't know, writing html. Oh wait, even html designers get it wrong. Oh well :) Yeah, gui builders aren't all they are cracked up to be. I am using CEGUI for my project, and I used the gui builder for a while, until I discovered that it randomly chose whether positions were stored as percent of screen size or pixel size, and I had to redo the whole thing manually. Don't criticize Marcus for not talking to other gui developers about their gui's problems, as far as I know, he was the first :) For me, I probably wouldn't purchase a gui toolkit. I have written some in the past, and find writing guis rather enjoyable. If I want to actually work on a game rather than a gui, I will look at what's out there and use it if I feel like it. Both PGU and ocemp really look like they control how I would write the game, which I think is fine in PGU's case, it's meant to be sort of a quickstart, not a last minute plugin. CEGUI definitely has influenced how I have programmed my game, but it has also saved me some time. If I couldn't find a suitable free library though, I would probably write my own toolkit as you have just done. Trolltech has succeeded with QT because is is usable in so many places for many different operations, and is also used in one of the two most popular linux desktops: KDE. If it weren't for their liscensing though, I can't help but think that GTK would not have done as well as it has. For a toolkit that can only be used in pygame, ignoring things like pyopengl, python-ogre, etc, such limited use I don't see as being very marketable. If it was generalized, and pluginable to almost any python program, that starts to have some real value.
Re: [pygame] New GUI
On, Tue Jan 22, 2008, Kamilche wrote: > Marcus von Appen wrote: [...] >> Kamilche, as I am the OcempGUI head, I'd like to hear where exactly your >> problems and expectation were (and still are) regarding an user interface >> system for your applications and games. >> >> Regards >> Marcus > > Sure. I've attached a more thorough critique of some of the features in > Ocemp GUI, since you're interested. Answering this will become a bit off topic, but as there are some more people reading this list, I guess answering some general things here is okay. The others will be answered off list. > General and UI Observations > > In mnemonics, '#' is used to denote the accelerator key, instead of '&' - > nonstandard. The mnemonics don't work with the right alt key, just the left > alt key. Basically the mnemonic solution is bad at all, not only in OcempGUI, but in any (major) toolkit I know: not fail-safe, unintuitive to use (doubled mnemonic character for the real character) and using the same mnemonic by accident on one form (due to a translation or an improper test) causes usability problems. I am however sure, that there is no standard, that declares '&' as mnemonic - just because other toolkits use it, do I have to? [] > The borders and window styles are non standard, and unattractive. > The font has hinting problems - a different font would be better. What's the standard for window and border styles and where it is defined? The default theme is in fact and without discussion far away from what one would consider 'nice looking' and already on the TODO list (for quite some time now...). [...] > By the end, you realize it requires 88 lines of code to create a simple > screen that doesn't DO anything. Ideally, a GUI builder should build it for > you and save the results to a file. In your code, you should just have to > say 'load thatscreen' and put in code to actually do program stuff. Show me a GUI builder that in fact produces clean, non-overloaded code, that does not break, if I manually change, add or remove stuff and so effectively eases development. I am not aware of any. If they do not match these criteria, but I am instead forced to stick with them (like e.g. VS.NET), they are useless. > I don't like having to execute a 'connect' for every button I want to > click. For standard controls and most situations, it's likely that the > parent of the button (the frame or the window) wants to handle the button's > click. Why do I have to code a connect for every little bit of So the Frame in which the Button resides handles its click. Clicking on the frame will then be handled by its parent and so forth? What about the topmost container then? To me that sounds like a weird implementation, but feel free to provide me a handy example for such an event handling.. > functionality? It would be better to have the 'obvious' cases automatically > handled, and reserve 'connect' and its ilk for global events that multiple > controls might want to handle. So the button gets clicked and how should it know (or the Frame) what to do? I still have to implement the callback. If I do it in the Button or Frame, does not matter here as it's the same effort and does not lower the work. > There's more, but I don't have time to review it further. I hope you find > this partial list of limitations useful. Sure. The feedback is highly appreciated. Regards Marcus pgpX2HxaMV6vb.pgp Description: PGP signature
Re: [pygame] New GUI
On, Tue Jan 22, 2008, Jasper wrote: > That's rather smug and presumptuous! Frankly, you have /no idea/ how I > went about hunting for a python GUI toolkit, nor I would guess anyone else > you're disparaging. No, it's exactly what I read in all places. I surely do not know, how you went about hunting ..., but you do not explain it as well. And your response, especially the last part seems to show, that such a mail was necessary in order to get some valuable feedback, not? ;-) > Moreover, you're knocking Kamilche for doing /precisely/ the same thing you > have done -- deciding you don't like any of the existing projects, and > starting your own. Bravo! I'm knocking _no one_. Instead I'm generalizing something, Kamilche said. I had my reasons (no working pygame GUI at the time I started writing OcempGUI) to write my own and surely Kamilche has his own. But instead of anyone saying 'all available toolkits do not match my criteria - there's none that works well enough for me', I'd like to hear _what_ does not work, _why_ not and what the user/developer expects. This would lower the work for both, the one who created the framework (-> better framework) and the one who wants to use it (-> no reimplementation needed). > In your search for suggestions, you have also glibly passed over several > specific points people were looking for, e.g. > - Do you have a nice GUI interface for laying out widgets? On which layer? The development layer or visible components? For the first, I would say yes, the second is somewhat ugly looking at the current trends for visualization components (default Gtk+ 1/2 like). > - Do you support transparent widgets? Yes. > - Do you have a framework for testing GUIs? GUI testing using tests is a somewhat impossible task, if you think about automated tests. If you mean some handy integration checks, please be more specific on what you mean here. In general, there are no tests for OcempGUI as an automated test usually does not behave like an end user. Regards Marcus pgpLETyeTlTmy.pgp Description: PGP signature
Re: [pygame] New GUI
On Jan 22, 2008, at 12:27 PM, Kamilche wrote: Casey Duncan wrote: My own pygame dev being at the hobby-level, I can't say that I would have much interest in a commercial add-on to pygame myself. However, I would be interested in a high-level overview of what you found wrong with the existing guis and how your solution does not suffer from these perceived problems. From a business standpoint, you might have trouble marketing such a thing in the face of the incumbent free solutions, regardless of how superior it might be. The dual-pricing scheme that Laura mentioned could help encourage adoption. Another option might be two versions, a bare-bones open source library that is functional but has few bells and whistles (perhaps lacking the gui builder), and a commercial upgrade that has everything anyone could want. Yeah, that's true. I wish there had been something like mine available at the time I started my project - I would certainly have used it and saved myself lots of trouble. When push comes to shove, the worst drawback of all the Pygame GUI's, is not having a GUI builder. It's offensive to me, to have to write code to draw a screen! Interesting, I actually prefer that. I typically find code generation offensive. Ideally (In my mind) a GUI that had GUI builder would not require it. Funny how different people are sometimes 8^). That said, I want a system that is highly automated and "just works" for the typical case, not requiring reams of code and refactoring of my game just to get started. I know lots of people would love this GUI I put out, and it existence would help promote the Python language as a whole. But you're right, there are lots of free GUI's out there. If I do end up making it available, I'll probably do something like 'free for free software projects, but if it's used in a commercial or shareware software project, there's a licensing fee of $100 per developer' or some such thing. I myself am pretty sensitive about licenses. You could have the best software ever written, but if the licensing is too difficult for me to understand or has too many arbitrary restrictions I'll use something else or go write my own. Also licenses have a strong affect on whether I want to contribute to a project, regardless of whether I use it or not. What's my motivation to contribute to something that makes money for someone else? These are all things to consider. I'm not sure whether or not to release it. There's a difference between 'Good enough to use in house' and 'Good enough to sell, complete with examples, documentation, and help.' Indeed, releasing things is hard sometimes. Setting realistic expectations helps though, as does a demonstrated commitment to keeping the thing going over time. What I REALLY want, is people to collaborate on it with me, adding enhancements and new controls. I suppose I could just get it out there in base form, but with the licensing in place, and see if enough people are inspired by it to make it take off. Making a community around a project is very rewarding and a lot of work. It also requires you to give up some amount of ownership and control over your project. Opensource is the ultimate meritocracy though, if its useful, they will come. Also with guis the barrier to entry (i.e., hello world and something useful) needs to be pretty low for it to catch on. It needs to not dictate how I write my whole game, it needs to be easy to integrate with an existing (py)game. It needs to make common things easy and hard things possible, etc. Mostly it needs to stay out of my way and let me do it the way that is right for me. Pygame itself is successful IMO largely because it gets these things right. -Casey
Re: [pygame] New GUI
Jasper, my Gmail account say that your mail server is a spam sender. :-/ 2008/1/22, Jasper <[EMAIL PROTECTED]>: > > That's rather smug and presumptuous! Frankly, you have /no idea/ how I > went about hunting for a python GUI toolkit, nor I would guess anyone > else you're disparaging. > > Moreover, you're knocking Kamilche for doing /precisely/ the same thing > you have done -- deciding you don't like any of the existing projects, > and starting your own. Bravo! > > In your search for suggestions, you have also glibly passed over several > specific points people were looking for, e.g. > - Do you have a nice GUI interface for laying out widgets? > - Do you support transparent widgets? > - Do you have a framework for testing GUIs? > > -Jasper > > Marcus von Appen wrote: > > On, Tue Jan 22, 2008, Kamilche wrote: > > > > [Unhappiness about the existing GUIs] > > > > It's interesting to see that a lot of people tell some public > > list/forum/whatever how unhappy they are with existing solutions, but do > > not dare to get into touch with any of the solution developers or even > > describe the problem areas they see somewhere. > > > > It explains, why there's so much lousy software on the market. People > > just complaining, but not helping in any way. > > > > Kamilche, as I am the OcempGUI head, I'd like to hear where exactly your > > problems and expectation were (and still are) regarding an user > interface > > system for your applications and games. > > > > Regards > > Marcus > > > > -- Juan José Alonso. KarlsBerg. eMail: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED]
Re: [pygame] New GUI
Casey Duncan wrote: My own pygame dev being at the hobby-level, I can't say that I would have much interest in a commercial add-on to pygame myself. However, I would be interested in a high-level overview of what you found wrong with the existing guis and how your solution does not suffer from these perceived problems. From a business standpoint, you might have trouble marketing such a thing in the face of the incumbent free solutions, regardless of how superior it might be. The dual-pricing scheme that Laura mentioned could help encourage adoption. Another option might be two versions, a bare-bones open source library that is functional but has few bells and whistles (perhaps lacking the gui builder), and a commercial upgrade that has everything anyone could want. Yeah, that's true. I wish there had been something like mine available at the time I started my project - I would certainly have used it and saved myself lots of trouble. When push comes to shove, the worst drawback of all the Pygame GUI's, is not having a GUI builder. It's offensive to me, to have to write code to draw a screen! I know lots of people would love this GUI I put out, and it existence would help promote the Python language as a whole. But you're right, there are lots of free GUI's out there. If I do end up making it available, I'll probably do something like 'free for free software projects, but if it's used in a commercial or shareware software project, there's a licensing fee of $100 per developer' or some such thing. I'm not sure whether or not to release it. There's a difference between 'Good enough to use in house' and 'Good enough to sell, complete with examples, documentation, and help.' What I REALLY want, is people to collaborate on it with me, adding enhancements and new controls. I suppose I could just get it out there in base form, but with the licensing in place, and see if enough people are inspired by it to make it take off. --Kamilche
Re: [pygame] New GUI
Marcus von Appen wrote: On, Tue Jan 22, 2008, Kamilche wrote: [Unhappiness about the existing GUIs] It's interesting to see that a lot of people tell some public list/forum/whatever how unhappy they are with existing solutions, but do not dare to get into touch with any of the solution developers or even describe the problem areas they see somewhere. It explains, why there's so much lousy software on the market. People just complaining, but not helping in any way. Kamilche, as I am the OcempGUI head, I'd like to hear where exactly your problems and expectation were (and still are) regarding an user interface system for your applications and games. Regards Marcus Sure. I've attached a more thorough critique of some of the features in Ocemp GUI, since you're interested. General and UI Observations In mnemonics, '#' is used to denote the accelerator key, instead of '&' - nonstandard. The mnemonics don't work with the right alt key, just the left alt key. In radio buttons, multiline text is centered by default. It really should be left aligned. There'e no 'pygame.quit' at the end, so after running, the examples hang and you have to manually close the DOS box. This makes them hang in IDLE as well. The borders and window styles are non standard, and unattractive. The font has hinting problems - a different font would be better. There's no selection capability on the text edit boxes - you can't drag your mouse to select text, have it highlight, and do standard text editing on it. Many examples are so simple as to be useless, such as the 'event.py' example. An event showing a button actually executing code when clicked would be good, instead of showing a 'picture of a button' in one example and showing an 'event that's raised' in another example. In the 'example.py' application, the 'box' entry shows 4 items placed on top of each other. Clicking on the background items brings them to the foreground, and they never go back. Was that intentional? Why are they changing zorder? This is not obvious to me. In the file dialog example, clicking '..' when at the top doesn't bring you to the list of drives. You have to manually overtype drive C with drive D using the limited editing capability allowed in the folder name box. The image map example suffers from performance problems. Just moving the mouse over the imagemap box causes events to queue up and get rendered so slowly, you quickly wonder if the example is broken. A single swish of the mouse from left to right, and you have to wait 3 seconds for the display to catch up. The sliders suffer a performance problem as well. Dragging the sliders isn't instant, you have to wait for it to catch up to the mouse. The 'hello world' examples have an unpainted area to the right of the window, that is picking up whatever was underneath when the window was created. The main window is not resizable. The status bar is not recognizable as such, it looks like a frame with text in it. It needs to look like a status bar, and have multiple panels you can set. The toggle buttons don't look any different than depressed normal buttons. Toggle buttons usually look significantly different than normal buttons, by such hints as having a different shape, different shading, or graphics on them as well. There are no examples of an FPS indicator, a global event that several controls might want to handle. The tooltip makes no attempt to stay on screen - it gets cut off on the right. The window example is too small - it shows a single button that you can click. I would like to see window examples throughout the examples, not just this unrealistically simple example. No fullscreen mode available. No 3d option for the text. No menus. No way to enlarge/shrink controls when the window size changes. Code Observations - I don't have time to critique all the example code, so I just ran through the 'radio.py' example. 'from ocempgui.widgets import *' - pollutes namespace After creating a table, you must set the alignment explicitly for each row. Why not have the most common alignment, which is probably align_top, the default? table.set_row_align (0, ALIGN_TOP) table.set_row_align (1, ALIGN_TOP) When creating radio buttons in a loop, you must specify the group manually with an if switch. Why not have all radio buttons that belong to the same parent, automatically in the same group? btn = RadioButton (s, group) if i == 0: group = btn By the end, you realize it requires 88 lines of code to create a simple screen that doesn't DO anything. Ideally, a GUI builder should build it for you and save the results to a file. In your code, you should just have to say 'load thatscreen' and put in code to actually do program stuff. I don't like having to execute a 'connect' for every button I want to click. For standard controls and most si
Re: [pygame] New GUI
That's rather smug and presumptuous! Frankly, you have /no idea/ how I went about hunting for a python GUI toolkit, nor I would guess anyone else you're disparaging. Moreover, you're knocking Kamilche for doing /precisely/ the same thing you have done -- deciding you don't like any of the existing projects, and starting your own. Bravo! In your search for suggestions, you have also glibly passed over several specific points people were looking for, e.g. - Do you have a nice GUI interface for laying out widgets? - Do you support transparent widgets? - Do you have a framework for testing GUIs? -Jasper Marcus von Appen wrote: On, Tue Jan 22, 2008, Kamilche wrote: [Unhappiness about the existing GUIs] It's interesting to see that a lot of people tell some public list/forum/whatever how unhappy they are with existing solutions, but do not dare to get into touch with any of the solution developers or even describe the problem areas they see somewhere. It explains, why there's so much lousy software on the market. People just complaining, but not helping in any way. Kamilche, as I am the OcempGUI head, I'd like to hear where exactly your problems and expectation were (and still are) regarding an user interface system for your applications and games. Regards Marcus
Re: [pygame] New GUI
On, Tue Jan 22, 2008, Kamilche wrote: [Unhappiness about the existing GUIs] It's interesting to see that a lot of people tell some public list/forum/whatever how unhappy they are with existing solutions, but do not dare to get into touch with any of the solution developers or even describe the problem areas they see somewhere. It explains, why there's so much lousy software on the market. People just complaining, but not helping in any way. Kamilche, as I am the OcempGUI head, I'd like to hear where exactly your problems and expectation were (and still are) regarding an user interface system for your applications and games. Regards Marcus pgpCPZG7g4J1e.pgp Description: PGP signature
Re: [pygame] New GUI
I've been unhappy with what's available as well (I'm currently using PyUI, with more than a few hacks). I'd happily pay for a complete, reasonably architected, and supported pygame GUI. Especially if I could see/tweak the source, and the license allowed me to sell games using it. And double especially if some thought had gone into a GUI testing framework. -Jasper Kamilche wrote: I've looked at wxPython, PGU, Ocemp GUI, PyUI, and other GUI toolkits available for Python. Each of them had, to my eyes, severe flaws that prevented me from using them for my apps. Therefore, I've spent many months developing my own GUI and event system. The GUI has windowing, translucency, buttons, menus, slider bars, frames, and more. It has a drag n drop GUI builder. The controls can be 'anchored', meaning when you resize the window, the controls resize automatically as well. It has an easy event handling system similar to VB6, but also the capability for controls to handle 'global' events. I'm using it for a couple of commercial apps I'm making. I'm considering making the GUI itself available commercially, as well. I'm writing this email to gauge the level of interest in it. If you're interested, respond in this thread. Pricing is an unknown - if you have thoughts in that area, I'd appreciate hearing them. --Kamilche
Re: [pygame] New GUI
Hi Kamilche Being a blind user and the need for an all text version. It would be nice to have something that is complete text oriented. I have not tried any for the screen does not allow the screen reader to scan unless it is standard Window Classic with classic colors and standard buttons and menus. A text version that has menus that say the same things as fancy buttons and such do. The menus must be of the standard windows style as I mentioned. Search functions and such as a part of menus That is what is ideal for a blind user. Bruce I've looked at wxPython, PGU, Ocemp GUI, PyUI, and other GUI toolkits available for Python. Each of them had, to my eyes, severe flaws that prevented me from using them for my apps. Therefore, I've spent many months developing my own GUI and event system. The GUI has windowing, translucency, buttons, menus, slider bars, frames, and more. It has a drag n drop GUI builder. The controls can be 'anchored', meaning when you resize the window, the controls resize automatically as well. It has an easy event handling system similar to VB6, but also the capability for controls to handle 'global' events. I'm using it for a couple of commercial apps I'm making. I'm considering making the GUI itself available commercially, as well. I'm writing this email to gauge the level of interest in it. If you're interested, respond in this thread. Pricing is an unknown - if you have thoughts in that area, I'd appreciate hearing them. --Kamilche
Re: [pygame] New GUI
On Jan 22, 2008, at 8:00 AM, Kamilche wrote: I've looked at wxPython, PGU, Ocemp GUI, PyUI, and other GUI toolkits available for Python. Each of them had, to my eyes, severe flaws that prevented me from using them for my apps. Therefore, I've spent many months developing my own GUI and event system. The GUI has windowing, translucency, buttons, menus, slider bars, frames, and more. It has a drag n drop GUI builder. The controls can be 'anchored', meaning when you resize the window, the controls resize automatically as well. It has an easy event handling system similar to VB6, but also the capability for controls to handle 'global' events. I'm using it for a couple of commercial apps I'm making. I'm considering making the GUI itself available commercially, as well. I'm writing this email to gauge the level of interest in it. If you're interested, respond in this thread. Pricing is an unknown - if you have thoughts in that area, I'd appreciate hearing them. My own pygame dev being at the hobby-level, I can't say that I would have much interest in a commercial add-on to pygame myself. However, I would be interested in a high-level overview of what you found wrong with the existing guis and how your solution does not suffer from these perceived problems. From a business standpoint, you might have trouble marketing such a thing in the face of the incumbent free solutions, regardless of how superior it might be. The dual-pricing scheme that Laura mentioned could help encourage adoption. Another option might be two versions, a bare-bones open source library that is functional but has few bells and whistles (perhaps lacking the gui builder), and a commercial upgrade that has everything anyone could want. -Casey
Re: [pygame] New GUI
In a message of Tue, 22 Jan 2008 08:00:49 PST, Kamilche writes: >If you're interested, respond in this thread. Pricing is an unknown - if >you have thoughts in that area, I'd appreciate hearing them. > >--Kamilche Trolltech has had great luck with a dual-pricing model for its Qt toolkit. Free for GPL'd products, and cost money for commercial use. see: http://trolltech.com/products/qt/licenses pricing structure for Qt. especially http://trolltech.com/products/qt/licenses/licensing/opensource/ There are also discounts for small business, and educational and academic use licenses. Laura
[pygame] New GUI
I've looked at wxPython, PGU, Ocemp GUI, PyUI, and other GUI toolkits available for Python. Each of them had, to my eyes, severe flaws that prevented me from using them for my apps. Therefore, I've spent many months developing my own GUI and event system. The GUI has windowing, translucency, buttons, menus, slider bars, frames, and more. It has a drag n drop GUI builder. The controls can be 'anchored', meaning when you resize the window, the controls resize automatically as well. It has an easy event handling system similar to VB6, but also the capability for controls to handle 'global' events. I'm using it for a couple of commercial apps I'm making. I'm considering making the GUI itself available commercially, as well. I'm writing this email to gauge the level of interest in it. If you're interested, respond in this thread. Pricing is an unknown - if you have thoughts in that area, I'd appreciate hearing them. --Kamilche
