TC4.1 - flnotify Options

[SamK]

The announcement of flnotify indicates "Position, size, colors customizable"
http://forum.tinycorelinux.net/index.php?topic=5113.0
The included flwm help shows how to customize time and position only. 

What are the parameters to configure size and colours?
   

[curaga]

The -g option configures both size and position. The -bg and -fg configure the background and text color, respectively.

Example: flnotify -g 400x500+0+0 -fg white -bg black "Hello world"

[SamK]

The -g option configures both size and position. The -bg and -fg configure the background and text color, respectively.

Thanks thats fine.

A couple of suggestions...

It might be worth adding a couple of lines to the flnotify "help" describing the colour setting.

When specifying a notification box size having a shorter horizontal length than the default, it is not possible to obtain placement on the right edge of the screen.  The left edge of the box remains in place and the length is trimmed from the right edge of the box leaving a gap to the right edge of the screen. 

In the attached screen shot flnotify used 200x100-0+0.  A similar effect is seen using 200x100 -r.  Perhaps it might be worth trimming the left edge of the box when placement at the right of screen is specified.

After thought - on examining the screen shot again it looks as though the vertical length is trimmed from the bottom of the box.  Might this be an issue if placement at the bottom of the screen is desired?
   

[curaga]

That just might be a FLTK bug. I can confirm the behavior, but I couldn't do anything to change it from the app.

The only change now would be the help text, and I'm reluctant to release a new version just for that.

[SamK]

That just might be a FLTK bug. I can confirm the behavior, but I couldn't do anything to change it from the app.

The only change now would be the help text, and I'm reluctant to release a new version just for that.

An idea...
Reduce the default box dimensions within flnotify. 

Scenario

• The user specifies placement at an edge of the screen
• When an increase in width or height is specified it will be added to the edge of the flnotify box that is furthest from the edge of the screen to which it is pinned
• Placement at the edge of the screen is obtained

   

[curaga]

An idea...
Reduce the default box dimensions within flnotify.

Yes, that works, but then there is text overflow for all not setting their own sizes. Trading for a worse issue IMHO.

The user specifies placement at an edge of the screen
When an increase in width or height is specified it will be added to the edge of the flnotify box that is furthest from the edge of the screen to which it is pinned
Placement at the edge of the screen is obtained

Perhaps you need to read the code. One can't tell FLTK to add width to this edge or that edge, you can only tell it the new size is XxY. Further, the -g code is completely outside the apps themselves, in FLTK.

[SamK]

Perhaps you need to read the code. One can't tell FLTK to add width to this edge or that edge, you can only tell it the new size is XxY. Further, the -g code is completely outside the apps themselves, in FLTK.

The previous reference to specifying an edge to adjust is an indication of my unfamiliarity with FLTK.  Such references are probably now best disregarded.  As a non-coder reading the code is not open to me.  I offered the suggestion based on observed behaviour in which the app makes the choice.

The screen shot provided in reply #2 was the result of 200x100-0+0 i.e smaller than the default of flnotify.  It produced a box of the correct size but not the desired location.  Interestingly, the top-left corner of the box is located in the same position as a box of the default size.  Is this a coincidence?

It is almost as if a box of of the default size is first created with its top-right corner referenced to -0+0, which in turn produces a location for the top-left corner.  Secondly a box of the user specified size is created, from a reference point of the top-left corner of the default box.  Because this is shorter, the location of the top-left corner is unaffected, resulting in the gap between the top-right corner and the edge of the screen.

The attached screen shot uses 500x300-0+0 i.e. larger than the default of flnotify.  It produces a box of the correct size and is in the desired location.  Here the top-left corner is not at the same location as a default box.

It is almost as if a box of of the default size is first created with its top-right corner referenced to -0+0, which in turn produces a location for the top-left corner.  Secondly a box of the user specified size is created, from a reference point of the top-left corner of the default box.  Because this is longer, the location of the top-left corner must change to accommodate it in order to remain within the screen boundary, resulting in the box presenting as specified.



If the conclusions drawn from the observations are correct, reducing the size of the flnotify default box size will (largely) overcome the matter as the user will specify only sizes that are larger than the default.

[curaga]

Yes, that is the behavior, and I still think it's a bug in FLTK. As the 1.1 series is no longer under active maintenance, a bug report may not get much attention unfortunately.

For reducing the default size, as said, I assume most users will not specify a size unless they need more space than the default. With a smaller size the messages I used for measurements would overflow: (slightly exaggerated example)



I understand that the default may be too big for your uses, but making it much smaller would be a bigger inconvenience.

[SamK]

I understand that the default may be too big for your uses,...

Flnotify is entirely usable in its current form and I am grateful that you chose to add it to the repo.  The size is a cosmetic matter rather than functional one.  To me, an option to specify the size is both accepted and welcomed.  The suggestions made in reply #2 are given in the spirit of helping where I am able to, rather than being motivated by self interest.  Without being in any way contentious, the intention was to identify two anomalies and ways they might be addressed for the benefit of everyone.

...but making it much smaller would be a bigger inconvenience.

Convenience of use is normally an important consideration. In this case it might not be quite so important given the nature of flnotify.  To use it successfully a user must have some technical acumen and understanding of the app's use.  The latter might be obtained from its help facility (or now this thread).  Then a message source has to be created and fed in via a command line.  Such a user is unlikely to baulk at a size parameter.  A casual user, or one without the requisite skill or inclination is likely to use a pre-made desktop environment that contains an in-built notification mechanism.