MUI allows you to colour text, but I'm getting inconsistent results on Workbench vs custom screens.
If I use "\e8" then I think that means it uses HIGHLIGHTTEXTPEN, which I think is what I *should* be using as it is described as "special color text, on background". On my Workbench that gives nice easily readable blue text... but on custom MUI screens it becomes horribly hard to read white text (since it is on a pale background). I can fix this with Sys:Prefs/Screens, by telling it to use Palette "Like Worbench", but how many users are going to do that?
If I use "\e5" then I think that means it uses FILLPEN, which may not be appropriate since it is described as "active-window/selected-gadget fill". However, on both my Workbench & custom MUI screens it gives nice easily readable blue text.
So I'm kinda stuck: Use the "correct" pen & get horrible results on custom MUI screens. Or use the "wrong" pen & get the right result on custom screens... but possibly(?) risk getting the wrong colour if the user did some wierd customisation of window border colours.
Any thoughts on what is the best approach? Or is there a solution I didn't consider?
Any thoughts on what is the best approach? Or is there a solution I didn't consider?
Raise an issue on the MUI bugtracker?
Actually I think opening the screen as "like WB" *is* the correct approach. This should be the default anyway - certainly it is if you add a new screen through MUI Prefs.
The GUI colours are pens, not ARGB values, so the best MUI can do on a particular screen is use the pen you've asked it to use. If that isn't the right colour then you'll need to set your own colour palette (although I'm not sure you should be messing with the user's choice for HIGHLIGHTTEXTPEN on a particular screen - if you can't read it, it's your settings that are wrong, not mine!)
If you need specific colors then you should obtain a suitable pen using graphics/ObtainBestPen() before and then tell MUI to use this pen by something like "\033p[pennumber]". Don't forget to finally release the pen again before program termination.
MUI does not make any assumption about specific colors for the standard pens. These are defined by Intuition and unless you did not change them or requested something like "Like Workbench" they will default to the internal default colors of Intuition.
Finally, you really should no longer refer to the old and ancient documentation on sasg.com. This is limited to MUI 3.8 anyway. Up to date Autodocs can be found in each release archive on http://muidev.de/downloads.
Finally, you really should no longer refer to the old and ancient documentation on sasg.com. This is limited to MUI 3.8 anyway. Up to date Autodocs can be found in each release archive on http://muidev.de/downloads.
Two things: 1. There are no MUI4 autodocs available on the web (as HTML pages), so I can't point to something which doesn't exist. If it's not on the web then it doesn't exist (But I didn't use the website for my actual research.) 2. I tend to try to use AmigaOS3.x stuff & MUI3.8 stuff, since that is very portable.
Quote:
If you need specific colors then you should obtain a suitable pen using graphics/ObtainBestPen() before and then tell MUI to use this pen by something like "\033p[pennumber]". Don't forget to finally release the pen again before program termination.
That would have been great... except it appears to be a MUI4-specific feature, so I'm not sure how well it'd play with "alternative" OSes.
I'm also not sure how one can obtain a pen, when MUI windows might be moved to a different screen at any moment by the user.
Quote:
MUI does not make any assumption about specific colors for the standard pens. These are defined by Intuition and unless you did not change them or requested something like "Like Workbench" they will default to the internal default colors of Intuition.
Not defaulting to "Like Workbench" seems a bit user-unfriendly: Most of the time the user WANTS their screen it look similar to Workbench. In the few cases they don't, then they could always fiddle with Prefs options.
I tend to try to use AmigaOS3.x stuff & MUI3.8 stuff, since that is very portable.
The Autodocs of MUI 3.8 are far from being complete. MUI 3.8 offers more than is actually documented. If you would have tried you would have noticed that something "\033P[17]" actually does work and correctly uses pen #17 for the following text.
Quote:
That would have been great... except it appears to be a MUI4-specific feature, so I'm not sure how well it'd play with "alternative" OSes.
See above. It is working, although not yet documented.
Quote:
I'm also not sure how one can obtain a pen, when MUI windows might be moved to a different screen at any moment by the user.
This is one of the oldest features called "subclassing". Refer to the source of Demos/Class2 for details. Honestly, you can do lots of things with just using the basic classes provided by MUI. But if you really want to do some serious development using MUI including some fancy stuff then creating subclasses is the only way to go.
Custom pens must be obtained in the MUIM_Setup method and released again in MUIM_Cleanup. Between these two methods the pen can be used. Switching to a different screen will call MUIM_Cleanup first and MUIM_Setup again as soon as the new screen is ready. This ensures that the pen will be obtained for the correct screen.
Quote:
Not defaulting to "Like Workbench" seems a bit user-unfriendly: Most of the time the user WANTS their screen it look similar to Workbench. In the few cases they don't, then they could always fiddle with Prefs options.
Then MUI 3.8 must be considered "user-unfriendly", because it doesn't offer this automechanism yet. Better switch to MUI 3.9 at least, or even better directly to MUI4.
@tboeckel Thanks for the hints. I'll take a look at them when I have time.
Quote:
Then MUI 3.8 must be considered "user-unfriendly", because it doesn't offer this automechanism yet. Better switch to MUI 3.9 at least, or even better directly to MUI4.
I didn't mean to pick on MUI specifically. AmigaOS4 itself still has a few "user-unfriendly" quirks inherited from OS3.x days (and even one or two new ones IMHO).
@tboeckel & any other resident MUI experts I finally had time to look at allocating pens with MUI & the Class2 example, but I've run into a problem:
I want to use MUI_ObtainPen(), but it doesn't appear possible to define the initial colour of a MUI_PenSpec structure, without first creating a MUI_Poppen (or MUI_Pendisplay) GUI element? Unfortunately I'm not able to offer such a GUI element for this colour (I know this is undesirable, but please don't argue this point).
So it seems impossible to use MUI_ObtainPen() to allocate a specific colour. Which means I'm going to have to use ObtainBestPen() instead, which seems rather hackish (although it appears I can use muiRenderInfo to get the window's current screen for the necessary viewport colourmap needed by ObtainBestPen())...
I would suggest using the MUI pens as they are supposed to be used, i.e. HIGHLIGHTPEN for highlighting, FILLPEN for fill colour etc. Then if it looks like shit on a custom screen (it always does) the user needs to do some configuration to get it right.
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
I want to use MUI_ObtainPen(), but it doesn't appear possible to define the initial colour of a MUI_PenSpec structure, without first creating a MUI_Poppen (or MUI_Pendisplay) GUI element? Unfortunately I'm not able to offer such a GUI element for this colour (I know this is undesirable, but please don't argue this point).
struct MUI_PenSpec is just a wrapper for simple strings. This has been done to ensure correct variable types for functions like MUI_ObtainPen(). But since a pen spec is in fact just a simple NUL terminated C string you can use all the well known string functions.
I admit that the current MUI Autodocs really miss a good example how a valid pen spec has to look like. I will update the docs as soon as possible.
MUI knows 5 different pen types: 1. system pens, i.e. "s0". This is equivalent to using the pens from muiRenderInfo(obj)->mri_DrawInfo->dri_Pens directly. 2. MUI pens, i.e. "m5". This is equivalent to using the pens from muiRenderInfo(obj)->mri_Pens directly. 3. palette entries, i.e. "p42". This will use pen #42 from the screen's current palette. This kind of spec should only be used if you really know which color you get as no allocation is done. 4. RGB values, i.e. "rRRGGBB" or "rRRRRRRRR,GGGGGGGGG,BBBBBBBB". This kind of spec will allocate a pen with the given RGB values (either 3x8 bit or 3x24 bits) 5. an empty string. This will use the default text pen/color.
No matter which kind of spec you use in the end you eventually must always call MUI_ReleasePen() for each obtained pen.
When using a pen during a drawing operation all obtained pen values must never be used directly, but must always be used together with the MUIPEN() macro.
Quote:
So it seems impossible to use MUI_ObtainPen() to allocate a specific colour. Which means I'm going to have to use ObtainBestPen() instead, which seems rather hackish (although it appears I can use muiRenderInfo to get the window's current screen for the necessary viewport colourmap needed by ObtainBestPen())...
This is not hackish at all, because internally MUI does exactly the same for RGB specs. However, it is recommended to always use MUI_ObtainPen() to be able to handle aribtrary pen specs. You don't have to care about any details or possible pit falls then.
@Deniil You might be interested to know that I ended-up writing a (PortablE) OOP wrapper, so I can have a normal object (rather than all that BOOPSI crap) when creating a custom MUI class . Makes the actual code for my custom class MUCH shorter! I imagine that (at least AmigaE) programmers must have done such a thing many times before, since it's kinda obvious thing to want.
@tboeckel Thanks for all your info. I have successfully implemented a custom class to allocate a pen, using both the ObtainBestPenA() & Mui_ObtainPen() solutions.
There's a slight (but expected) problem where changing screens causes the pen to be reallocated... but existing MUI text contains references to the old pen. Regenerating the text obviously fixes that, but I can't (easily) do it automatically since the text is generated from a relatively slow on-disk database + my portable GUI abstraction doesn't have the concept of the GUI requesting the app refresh it's GUI.
And even if I *could* regenerate all the coloured text in my rather large NListviewObject, it seems a bit silly (and onerous) for MUI to require all the text to be regenerated (potentially in all the program's MUI windows) just because the window moved to a different screen. i.e. It seems a bit silly that a low-level GUI implementation detail (pen colours changing when the window moves to a new screen) requires a high-level operation to occur (regenerating all the text in it's MUI windows).
My suggestion is that MUI should add an extra level of abstraction - by adding the concept of "logical user pens". Instead of calling Mui_ObtainPen(), you would called Mui_ObtainLogicalPen(). This would return a "logical pen" number that only has meaning for that particular MUI program. The "logical pen" number would be an index into a table containing the actual pen numbers, and only text strings could refer to logical pens (using say "\033L[logical pen number]"). (When the window was moved to a different screen, ideally MUI would automatically reallocate logical pens, but it could still be left to the MUI program.) The text colour would still be correct because the logical pen number would be unchanged, while the underlying real pen number would have been updated.
Well, I'm not demanding you implement this idea, just suggesting it as a possible improvement to MUI which would (IMHO) make some MUI programs easier (and/or more efficient) to write.
Edited by ChrisH on 2015/6/13 8:53:05 Edited by ChrisH on 2015/6/13 8:54:30 Edited by ChrisH on 2015/6/13 9:33:53 Edited by ChrisH on 2015/6/13 11:40:25
@tboeckel I ran into another problem - sometimes I want to create the display string before the window is even open (and thus the pen number cannot be known). Logical pens could solve this also, if they let the caller specify the logical pen number when obtaining it.
Since my colour formatting was simple enough, I ended-up implementing my own "logical pens" kludge (basically the NList display hook overwrites the pen number in the string, if the pen number stored in an indexed array has changed).
Currently there is no other way than creating the full text from scratch to make sure that the possibly changed pen numbers are used correctly. Although the suggestion of indirect pens might sound like a good idea on the first sight I'd suggest to go for direct RGB colors instead. With these there is no need to obtain any pens at all and you will always get the desired result, no matter how many pens have been obtained for a specific screen by other applications already.
I can guess your next objection already: direct RGB values will not work on colormapped screens. Yes, this is true. But 8bit colormapped screens really belong to the past. If you want colorful text and graphics then hi/truecolor screens are the only way. If people really think they must use 8bit colormapped screens then they will end up with simple black text, unless you support both pens and direct RGB colors.
MUI's internal text engine is already able to use direct RGB colors (i.e. \033P[RRGGBB] or even \033P[AARRGGBB] for alpha blended text), unfortunately NList has its own text engine. Although it looks very similar to MUI's text engine there are some important differences and support for direct RGB colors is yet missing. Go ahead and open an enhancement request for such a feature. Alternatively you might want to consider switching to MUI's own List.mui class which makes use of MUI's text engine with all its features described in the Autodocs of Text.mui.
unfortunately NList has its own text engine. ... support for direct RGB colors is yet missing.
Thanks for letting me know. Saved me puzzling why your suggestion doesn't work.
Quote:
you might want to consider switching to MUI's own List.mui class
IIRC, I did originally use that, but it didn't support everything I wanted. Unfortunately I can't recall what.
Quote:
I'd suggest to go for direct RGB colors instead
That's not something I'd actually considered (I guess I was focused on getting pens to work). I'm not too worried about 8-bit screens, but it would be nice.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
(But I didn't use the website for my actual research.)
