Page 1 of 3

I can help with visual GUI designer for ReactOS

Posted: Wed Oct 10, 2007 6:42 pm
by mrhx
Hi, all.

I am the developer of a visual GUI builder which is able to generate the pure win32api code in several programming languages. The generating process is wholly tunable.

I'll be glad, if my project helps ReactOS developers.

Download here: http://mrhx.ucoz.com/

Posted: Wed Oct 10, 2007 7:11 pm
by Nixer
Here is the direct link for download: http://mrhx.clan.su/load/0-0-0-92-20

Posted: Wed Oct 10, 2007 8:13 pm
by Z98
Fireball (Aleksey) finds the concept interesting. We'll see how things turn out.

Posted: Thu Oct 11, 2007 12:28 am
by oiaohm
This is something that has been missing from Windows Development.

One question closed source or open source? Did not see a source archive or a svn/cvs anywhere. Might have just missed it.

Most likely will be used either way. Open source may see it ported to linux on libwine to be used with the reactos build env under linux.

I will have to try this in wine under linux to make sure it usable to developers working over there on ros as well. Note reason gcc ros uses still works better under linux than windows.

Posted: Thu Oct 11, 2007 8:11 pm
by mrhx
oiaohm wrote: One question closed source or open source? Did not see a source archive or a svn/cvs anywhere. Might have just missed it.
The source is closed, at present.
But I am thinking about opening it.

Posted: Sun Oct 14, 2007 1:10 am
by ThePhysicist
I agree the concept is interesting. I created a small program and it compiled without any problems on codeblocks + gcc.
But there were some problems. For example I couldn't use the date time picker, wich was located inside a tab control.

Some other things:
- The tab control could need a way to reorder the tabs (a move up and move down button)
- When placing controls inside the tab control, they will be associated to the current tab only if you resize them after plaing them there. And sometimes you can suddenly find your control on a different tab.
- when you specify WS_CLIPCHILDREN as main window style, the moving of windows looks a little messy. Should probably be diabled in working mode.
- The controls aren't moving with the window, if it is resized. This should be done for the status bar for example.
- I was missing the functionality of a menu (or am i just too stupid to find it?)
- Would be really nice to have some dialog box funtionality
- Allowing a set of basic commands would be cool, like show message box, open dialog box, show/hide/enable/diable control/menu, open commdlg dialog (open/close, colorpicker etc)
- maybe you could allow to specify names for the controls / the main window and rename the respective functions like MainWindowName_OnCreate(), Button1_OnClick(), Statusbar_OnSize or something like that.

All in all: nice work, keep it up.

Posted: Sun Oct 14, 2007 10:29 am
by mrhx
ThePhysicist wrote:I couldn't use the date time picker, wich was located inside a tab control.
The date time picker didn't work after compilation or at design time ?

The Other things, that you've said, I've written it down to fix later. Thank you.


PS: Who knows why my tooltips don't work properly in Wine?
I subclass the tooltip control and paint it on wm_paint message.
But in wine and reactos, it doesn't work :(

Posted: Sun Oct 14, 2007 10:31 am
by Phalanx
mrhx wrote:
ThePhysicist wrote:I couldn't use the date time picker, wich was located inside a tab control.
The date time picker didn't work after compilation or at design time ?

The Other things, that you've said, I've written it down to fix later. Thank you.


PS: Who knows why my tooltips don't work properly in Wine?
I subclass the tooltip control and paint it on wm_paint message.
But in wine and reactos, it doesn't work :(
If that works good in Windows, then I would place it down as a bug (it would be one that may be hard to tell with normal programs).

Posted: Sun Oct 14, 2007 11:36 am
by mrhx
I've made some screenshots about this bug:

(1) This was before, at the time when my app did not paint the tooltips manually.

ROS:

[ external image ]

It worked good.

(2) Now my app paints tooltips itself.

winxp:

[ external image ]
[ external image ]

ROS:

[ external image ]
[ external image ]


As you may see, the button tooltip has the same size as in winxp.
This is correct, but it is not painted. I think, it's because ROS paints the tooltips not via WM_PAINT.

And the second: the window tooltip with little screenshot...
It is not painted and has wrong size.
I think, it's because this tooltip didn't have LPSTR_TEXTCALLBACK as its caption (in other words, it has direct caption). I resize the tooltip on TTN_SHOW message. But, as I see, there is no such message for the window tooltip. But the winapi documentation says TTN_SHOW is sent when the tooltip is about to be shown. And no matter, has it LPSTR_TEXTCALLBACK or not. The button tooltip has LPSTR_TEXTCALLBACK instead of its caption, and it's resized correctly.

So, I think, there are two bugs:
1) painting tooltips not via WM_PAINT.
2) not sending TTN_SHOW, if the tooltip did not have LPSTR_TEXTCALLBACK.

Posted: Tue Oct 16, 2007 5:56 pm
by Phobos
ok, this is actually a very good and nice work...

it could be nice to have this included in reactOS, just like Mac OS X's (or originally, NextStep) Interface Builder is included for the cocoa programming

while it is not really needed to be open sourced, consider the advantages of doing so for development and maintenance...

keep it up!

VISG 0.95

Posted: Sun Mar 30, 2008 7:00 pm
by mrhx
New version 0.95 of VISG is available for downloading.
http://mrhx.ucoz.com/load/

+unicode support;
+jscript code generator;
+bugfixes;
+and more...

Posted: Mon Mar 31, 2008 12:13 am
by GreatLord
Hi
I look at the desgin I will not even test it.
for I dislike see everthing floating around the screen.
I want everthing holding toghter like a normal windows apps do.
not like a linux apps.

that why I refuse using gmp or other linux apps in windows or even linux gui. for all dialog and windows from diffent program floating around. and no way tell which beloing to what. I normal have around 10 diffent vs windows open. two photoshop windows, 10 or more explorer when I working. so letting thing floaring around not a sold background windows that holding thing toghter and letting box and dialog move inside other windows as well I hate shouch program.

Do not take it bad. I only tell what I think of u program. It is not only u program fall under this catogroue. not usable for me. GMP is one of the program goes under there as well

Posted: Mon Mar 31, 2008 12:29 am
by oiaohm
Ok GreatLord your a KDE person to a point. Non single window is a trait you see in GTK based applications on Linux and Windows.

http://developer.kde.org/documentation/ ... 8fig03.jpg
KDevelop dialog editor. Think that is more the style Greatlord likes.

Krita from koffice lot of image people like over gimp.
http://www.koffice.org/krita/pics/bala_krita1.6.png

I think its part the problem that gtk programs got ported first to windows. And a lot of Linux Distributions like using Gnome for some reason.

There are shockers of windows applications as well.

Posted: Mon Mar 31, 2008 1:51 am
by cppm
Slightly OT
GreatLord wrote: that why I refuse using gmp or other linux apps in windows or even linux gui. for all dialog and windows from diffent program floating around. and no way tell which beloing to what. I normal have around 10 diffent vs windows open. two photoshop windows, 10 or more explorer when I working. so letting thing floaring around not a sold background windows that holding thing toghter and letting box and dialog move inside other windows as well I hate shouch program.
Linux desktops tend to subdivide into workspaces, and you can group windows using some window managers. So it's less of a problem if you are on a real linux desktop.

Don't mean to sound like i'm randomly taking offence, it's just an interesting observation on the respective GUI metaphors.

PS: and as Oiahom points out, floating windows isn't really the linux standard per se. Plenty of linux apps use one central window (including GTK ones...) I gathered having lots of windows floating around was more a mac thing, or is that a poor observation?

(edit: since i was getting my terminology mixed up :oops: )

Posted: Mon Mar 31, 2008 8:54 am
by oiaohm
Most of the lot of windows floating about are left overs from early X11 gui design.

Gimp windows everywhere design is hated so much that there is a fork called gimpshop.

Problem with GTK is the idea of windows everywhere starts at the standard GUI editor. http://glade.gnome.org/screenshots.html

So I can understand if Greatlord would prefer something like the Kdevelop rad editor so people don't get the idea of coping a bad idea for most people.