[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.programming

BabyX, new feature for 0.4

Malcolm McLean

1/5/2015 10:03:00 AM

Baby X is a cross-platform GUI toolkit that's designed to be lightweight and easy to use.

It's up to 0.3 now,, and its pretty usable - it got a suite of high-level widgets for Christmas.

0.4 will feature some changes to the base. I've started work on cursors, with portable ANSI C functions to load Windows .cur files. It's handling the cursor as an interface to the underlying system cursor, so RGBA cursors are possible on Windows, but are going to be more difficult on X.

The question is whether to have a global cursor, or to attach one to each window. If, say, you're writing a paint package, and user selects "brush", you might want the brush cursor just in the main drawing canvas, or on all the windows. If you've got a splitter, you want the cursor to change to the splitter cursor when the user hovers, but not when he just crosses the splitter. If you're doing a long process, you want an animated hourglass (but often the system will pre-emept you on this anyway).

The more complicated the interface, the harder it is to use, and the more likely it is that there will be a problem on a port. So the Baby X way is to keep it simple.

On the todo list for 0.4 is cursors, splitters, tooltips, Arabic and Hebrew text, progress bars, kbhit, and audio.


BabyX url

http://sourceforge.net/proje...
5 Answers

kenobi

1/5/2015 10:28:00 AM

0

W dniu poniedzialek, 5 stycznia 2015 11:03:17 UTC+1 uzytkownik malcolm...@btinternet.com napisal:
> Baby X is a cross-platform GUI toolkit that's designed to be lightweight and easy to use.
>
> It's up to 0.3 now,, and its pretty usable - it got a suite of high-level widgets for Christmas.
>
> 0.4 will feature some changes to the base. I've started work on cursors, with portable ANSI C functions to load Windows .cur files. It's handling the cursor as an interface to the underlying system cursor, so RGBA cursors are possible on Windows, but are going to be more difficult on X.
>
> The question is whether to have a global cursor, or to attach one to each window. If, say, you're writing a paint package, and user selects "brush", you might want the brush cursor just in the main drawing canvas, or on all the windows. If you've got a splitter, you want the cursor to change to the splitter cursor when the user hovers, but not when he just crosses the splitter. If you're doing a long process, you want an animated hourglass (but often the system will pre-emept you on this anyway).
>
> The more complicated the interface, the harder it is to use, and the more likely it is that there will be a problem on a port. So the Baby X way is to keep it simple.
>
> On the todo list for 0.4 is cursors, splitters, tooltips, Arabic and Hebrew text, progress bars, kbhit, and audio.
>
>
> BabyX url
>
> http://sourceforge.net/proje...

as to mouse cursors, i never wrote such things but what i observe (here in opera app) i move
cursor over opera area and got 4 different cursor shapes depending over what im hovering: hand, arrow, I, and <-|->, also areas can change when cursor hover on that

what i will design the code, not sure probably
will add() function that would be building the tree of controls, in some mouse handling root
place i would send the messages down the tree;
if you asking about some specyfics releted to
winapi or x (if x is some like winapi for unix? i dont know) i dont know them. some troubles here?

could use your lib probably if got precompiled dll or lib for win32 and some well written short tutorial example how to use it; source was good (clean) loking as i already said

kenobi

1/5/2015 10:35:00 AM

0

W dniu poniedzialek, 5 stycznia 2015 11:28:31 UTC+1 uzytkownik fir napisal:
> W dniu poniedzialek, 5 stycznia 2015 11:03:17 UTC+1 uzytkownik malcolm...@btinternet.com napisal:
> > Baby X is a cross-platform GUI toolkit that's designed to be lightweight and easy to use.
> >
> > It's up to 0.3 now,, and its pretty usable - it got a suite of high-level widgets for Christmas.
> >
> > 0.4 will feature some changes to the base. I've started work on cursors, with portable ANSI C functions to load Windows .cur files. It's handling the cursor as an interface to the underlying system cursor, so RGBA cursors are possible on Windows, but are going to be more difficult on X.
> >
> > The question is whether to have a global cursor, or to attach one to each window. If, say, you're writing a paint package, and user selects "brush", you might want the brush cursor just in the main drawing canvas, or on all the windows. If you've got a splitter, you want the cursor to change to the splitter cursor when the user hovers, but not when he just crosses the splitter. If you're doing a long process, you want an animated hourglass (but often the system will pre-emept you on this anyway).
> >
> > The more complicated the interface, the harder it is to use, and the more likely it is that there will be a problem on a port. So the Baby X way is to keep it simple.
> >
> > On the todo list for 0.4 is cursors, splitters, tooltips, Arabic and Hebrew text, progress bars, kbhit, and audio.
> >
> >
> > BabyX url
> >
> > http://sourceforge.net/proje...
>
> as to mouse cursors, i never wrote such things but what i observe (here in opera app) i move
> cursor over opera area and got 4 different cursor shapes depending over what im hovering: hand, arrow, I, and <-|->, also areas can change when cursor hover on that
>
> what i will design the code, not sure probably
> will add() function that would be building the tree of controls, in some mouse handling root
> place i would send the messages down the tree;
> if you asking about some specyfics releted to
> winapi or x (if x is some like winapi for unix? i dont know) i dont know them. some troubles here?
>
> could use your lib probably if got precompiled dll or lib for win32 and some well written short tutorial example how to use it; source was good (clean) loking as i already said

ps do maybe someone knows what is general in usage in todays gui world? (know general questions hard to answer),
For example in general i tend to strongly hate windows explorer (shell) gui, that is damn weak
On contrary those "inpage" gui i see in opera is working light and clean (probably this is some customary solution of opera)

Richard Heathfield

1/5/2015 11:49:00 AM

0

malcolm.mclean5@btinternet.com wrote:

<snip>

> The question is whether to have a global cursor, or to attach one to each
> window.

That isn't a question that others can answer for you. But if you decide to
go with local cursors, I would do it like this (NB getcursor() is pseudocode
for whatever BabyX's cursor-pointer-getting function is called):

cursor = wnd->getcursor(); /* get THIS window's cursor */
if(cursor == NULL) /* haven't got one? Okay, we have a plan for that... */
{
if(parent != NULL)
{
cursor = wnd->parent->getcursor();
}
else
{
cursor = getglobalcursor();
}
}

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Malcolm McLean

1/5/2015 12:15:00 PM

0

On Monday, January 5, 2015 11:49:11 AM UTC, Richard Heathfield wrote:
> malcolm.mclean5@btinternet.com wrote:
>
> <snip>
>
> > The question is whether to have a global cursor, or to attach one to each
> > window.
>
> That isn't a question that others can answer for you. But if you decide to
> go with local cursors, I would do it like this (NB getcursor() is pseudocode
> for whatever BabyX's cursor-pointer-getting function is called):
>
> cursor = wnd->getcursor(); /* get THIS window's cursor */
> if(cursor == NULL) /* haven't got one? Okay, we have a plan for that... */
> {
> if(parent != NULL)
> {
> cursor = wnd->parent->getcursor();
> }
> else
> {
> cursor = getglobalcursor();
> }
> }
>

That sounds like a good system.

Windows made the design decision, bad in hindsight, to attach a cursor to each Window class.
So all the buttons and all the edit boxes have the same cursor, but a button doesn't necessarily
have the same cursor as an edit box.

I originally planned for Baby X to be good for mixing and matching under X, so I didn't define
a total Baby X hierarchy. I found that the experimental programs I was trying out always worked
best under Baby X only mode. But I'm not sure that still holds true, I can see someone wanting
the font picker dialog, for example, in a program which is otherwise non-Baby X . He's got to
pull in a an awful lot of files to do it, but some people don't mind that (in terms of bytes,
these days it's trivial).

kenobi

1/5/2015 12:55:00 PM

0

W dniu poniedzialek, 5 stycznia 2015 13:14:53 UTC+1 uzytkownik malcolm...@btinternet.com napisal:
> On Monday, January 5, 2015 11:49:11 AM UTC, Richard Heathfield wrote:
> > malcolm.mclean5@btinternet.com wrote:
> >
> > <snip>
> >
> > > The question is whether to have a global cursor, or to attach one to each
> > > window.
> >
> > That isn't a question that others can answer for you. But if you decide to
> > go with local cursors, I would do it like this (NB getcursor() is pseudocode
> > for whatever BabyX's cursor-pointer-getting function is called):
> >
> > cursor = wnd->getcursor(); /* get THIS window's cursor */
> > if(cursor == NULL) /* haven't got one? Okay, we have a plan for that... */
> > {
> > if(parent != NULL)
> > {
> > cursor = wnd->parent->getcursor();
> > }
> > else
> > {
> > cursor = getglobalcursor();
> > }
> > }
> >
>
> That sounds like a good system.
>
> Windows made the design decision, bad in hindsight, to attach a cursor to each Window class.
> So all the buttons and all the edit boxes have the same cursor, but a button doesn't necessarily
> have the same cursor as an edit box.
>
think that making a cursor slot in each entity
of any controll is a good idea, on NULl using the parent name (in designer way of what parency meand, may be on type or holder),
such decissions seem to be easy for me personally



> I originally planned for Baby X to be good for mixing and matching under X, so I didn't define
> a total Baby X hierarchy. I found that the experimental programs I was trying out always worked
> best under Baby X only mode. But I'm not sure that still holds true, I can see someone wanting
> the font picker dialog, for example, in a program which is otherwise non-Baby X . He's got to
> pull in a an awful lot of files to do it, but some people don't mind that (in terms of bytes,
> these days it's trivial).