On Friday 19 May 2006 01:02, Felipe Monteiro de Carvalho wrote:
> On 5/18/06, A.J. Venter <[EMAIL PROTECTED]> wrote:
> > You may well be right, although I have no idea how to do a borderless
> > window. My catch is I need this for a project due end of the month - so
> > I'll help you anyway I can :)
>
> MyForm.BorderStyle := bsNone;
Odd, I thought that didn't work under gtk1/2
>
> I think the start point should be a new unit, for the notification
> form. The form should be fully code generated. What is a good name for
> this unit? NotificationForm?
Well status message will be too easily confusable with statusbar messages.
What I would suggest is that it be a completely separate COMPONENT. Then
TrayIcon can have a handle to map to one.
The reason I am thinking of this is that it would mean anybody with a
different need could map one to just about any other component, hook it up to
the onshowhint event and use it for more bigger fold-out hints where those
are needed ? Thoughts anyone ?
So perhaps then the right name would be something like NotificationHint or
such ?
>
> My idea is to have 4 areas on the form:
>
> Title(TCaption) X button (TButton)
> TImage Display Area(either a TCaption or a
> custom control)
>
> It could be implemented in such a way that if Title and X button are
> disabled, then DisplayArea and TImage move to the top of the form. If
> TImage is disabled, Display Area moves to the left. I'm not sure what
> alignment properties to use here.
I like this.
>
> Also, should this window be created everytime it's shown? If not, then
> it needs to be created at some point.
I would say much rather have it created when whatever form it's attached to is
created, like any other component. In the case of a tray-icon, it will then
be created (hidden) along with the form the icon is connected to.
So the programmer just needs to worry about show and hide methods - it should
get created/destroyed along with the form it's used on.
>
> Also a system to have the display area contain either a caption or a
> custom control needs to be created.
I would use tcaption for now unless it really wouldn't work. It's allready
canvas drawn, works well and stably - and means we get it out faster.
> > KDE just closes on click or after a timeout - no need for an X.
>
> Ummm ... better to make it optional. I find it more confortable for
> the user to see the X. It can be confused and not know how to close
> the note immediately. Also Windows balloon has it, and they do a lot
> of expensive usability researches =)
Indeed, good point. Optional is the right way - then the coder can link it to
the desktop his users will be on - active for windows, disabled for KDE etc.
to integrate better into the over-all environment. I would leave the task of
figuring out what desktop you are on with the coder using it however - some
apps will only ever run on one platform/desktop - some on nearly every
lazarus supported one - we cannot really dictate this.
>
> > What I would suggest would be the coolest however is to make our window a
> > derivative of TIPiPRO htmlpanel.
>
> Ummm ... better to allow adding any component you like. I don't want
> to add any dependencies.
In retrospect, you are probably right.
>
> > I wouldn't bother with much else right now, rounded windows may look
> > pretty but they are very hard to do without relying on stuff like X
> > composite extensions.
>
> Yes, let's make it work. Latter someone can make it pretty.
Aye, there are lots of little widget-set specific stunts you can use to get
really funky window effects, but if somebody really wants those and (doesn't
mind not compiling against others) - he can code it in through the handle.
>
> Just tested latest subversion lazarus + trayicon. It's working normally.
Did you make any changes ? I'll test mine tomorrow (it's very late here)
>
> Looking back, I think I should have written it on pure X11. This would
> avoid many problems, like having to rewrite on gtk2, qt, reling on
> Handles that can change their meaning in the future, etc. But now it
> is working well, and Murphy says that if you change something that is
> working, it will stop working =)
Pure X11 however will have meant sacrificing a lot. For starters the options
for people to add some widget specifics using handles, even bigger - you
would STILL need custom implementations for other platforms (e.g windows and
carbon) - better then to be able to make maximum use of the underlying
platform. More work - but better IMHO.
Kina like my ScreenSize component uses two completely different approaches.
Under X platforms it uses Xlib calls to get the screen dimensions, under
windows it uses win32 api calls - but it provides a single clean component
that gives the same results on either, so your app can compile and get the
values regardless of what you are working on.
That approach is probably the thing that introduces the single biggest delay
in lazarus' growth rate - but at the same time it's also lazarus' most
powerful feature and well worth it.
If we had targetted only GTK1 we could probably have implemented exact clones
of every delphi component and call by now. But we'd be tied to a platform
that is fast becoming obsolete.
Anyway, enough philosophies, let me know if I can help you with the coding on
this.
A.J.
--
"there's nothing as inspirational for a hacker as a cat obscuring a bug
by sitting in front of the monitor" - Boudewijn Rempt
A.J. Venter
Chief Software Architect
OpenLab International
www.getopenlab.com
www.silentcoder.co.za
+27 82 726 5103
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
