Who's Online |
106 user(s) are online ( 64 user(s) are browsing Forums)
Members: 2
Guests: 104
BSzili, Prober,
more...
|
|
|
|
|
Re: MUI 4.0 keeps on expiring
|
Posted on: 2016/3/17 17:56
#21
|
Just popping in 
|
@Shamron
First MUI queries the ENV variables "KEYPATH" and "KEYFILES" for path specs to contain the file MUI.key. If these two fail it searches for the keyfile in these locations (and in this sequence):
MUI:
KEYPATH:
KEYFILES:
S:
L:
DEVS:
LIBS:
If a VALID keyfile is found in any of these locations then you end up with a fully registered MUI. Just having a file "MUI.key" with arbitrary contents in one of these locations is not enough. The key file is decrypted and checked to be valid.
Perhaps your key file has been modified while copying across several systems over the years. The keyfile check itself has been left untouched and is definitely working correctly.
|
|
|
|
|
|
Re: MUI 4.0 keeps on expiring
|
Posted on: 2016/3/17 6:38
#22
|
Just popping in
|
@djrikki
The latest nightly build is not older than 10 days and therefore is far away from expiring.
There is no need to complain. Nobody ever forced you to use the nightly builds. If you are not confident with the expiring mechanism then simply use the stable releases. Or check more often for updated nightly builds. These will definitely be created from scratch ahead of the final expiry date, even if there have been no changes inbetween.
|
|
|
|
|
|
Re: Odyssey 1.23 progress
|
Posted on: 2016/1/9 12:49
#23
|
Just popping in
|
@ kas1e
Because the catalog will be closed only if creating the application succeeded before. Otherwise you have a memory leak. Unprobable, but not impossible. I don't know how safety_check() and create_application() look like, but I suppose the catalog will be opened before the application is created.
|
|
Why stop it now, just when I am hating it?
Thore Böckelmann
|
|
|
|
Re: Odyssey 1.23 progress
|
Posted on: 2016/1/9 10:43
#24
|
Just popping in
|
locale_cleanup() should be called independently of the application object.
|
|
Why stop it now, just when I am hating it?
Thore Böckelmann
|
|
|
|
Re: Why is Serial Port Speed on os4 Limited to 31250 in PREFS? Please help
|
Posted on: 2015/12/16 6:37
#25
|
Just popping in
|
@magnetic
The baudrate set in Serial prefs only applies when the SER: driver is used. Any other application using serial.device directly will set a baudrate on its own and hereby override the global prefs.
|
|
|
|
|
|
Re: this version of MUI has expired??
|
Posted on: 2015/12/2 8:37
#26
|
Just popping in
|
@328gts
It is not possible to install an older MUI release over a more recent nightly build by just clicking "update" while being just a Novice or Advanced user. C='s Installer checks the individual versions and of course the nightly builds contain libraries and classes with more recent versions. Hence they will not be replaced with older versions automatically. Being an Expert user will let you choose the overwrite i.e. version 1.2 with version 1.1, but you will have to confirm this for each single file.
|
|
|
|
|
|
Re: Ringhio vs MUI bug
|
Posted on: 2015/11/6 8:02
#27
|
Just popping in
|
This must be a Ringhio issue, because all other windows on a MUI public screen restore the background correctly after moving/closing. I cannot tell what Ringhio is doing in this case, but the MUI public screen has a backfill hook to restore the intended background which gets called as soon as some portions of the screen become visible again. Complain at A-EON about this bug.
|
|
Why stop it now, just when I am hating it?
Thore Böckelmann
|
|
|
|
Re: Amiupdate problem
|
Posted on: 2015/11/3 18:16
#28
|
Just popping in
|
@all
I just removed the requirement for btree.library 53.3. Furthermore the next nightly build will contain exactly that version of btree.library. Everything should be fine then.
|
|
Why stop it now, just when I am hating it?
Thore Böckelmann
|
|
|
|
Re: YAM add group to address book
|
Posted on: 2015/10/29 14:54
#29
|
Just popping in
|
@JosDuchIt
No need for a bug report, because everything is working as expected. I just verified this myself.
Better check your NList Drag&Drop settings (MUI prefs -> NListviews -> Options tab). If Drag&Drop is set to "at the border" then you must drag the entry outside the list object to let the D&D process really begin.
If you take a look at YAM's Changelog file you will notice that the address book has not been touched since February 2014. That is almost two years ago by now. So it is very unlikely that there is a bug which has been introduced recently. An "external" cause like the NList settings is by far more probable.
|
|
Why stop it now, just when I am hating it?
Thore Böckelmann
|
|
|
|
Re: Poplace holder custom class error in Simplemail
|
Posted on: 2015/10/23 13:13
#30
|
Just popping in
|
@all MUI4 has a public bugtracker ( https://muidev.de/newticket) and also a big fat petition to report any bugs there on the very first page of MUI prefs. Is it really that hard to actually USE that bugtracker, instead of asking questions here? Even if an issue is confirmed by other users this will not fix the bug automagically as long as we don't know about it. And if there is a crash then at least the crashlog MUST be provided. Simply stating "it crashes" or "it doesn't work" is NOT enough and won't help anybody. Anyway, I just fixed this issue. The next nightly build of MUI4 will include a fixed Popplaceholder.mcc. At least it does not crash any longer on AmigaOS3 for me anymore. But please use the bugtracker IMMEDIATELY next time. Don't expect us to skim each and every forum for possible bug reports.
|
|
Why stop it now, just when I am hating it?
Thore Böckelmann
|
|
|
|
Re: Reaction (Screen Menus) and MUI (Context menues)
|
Posted on: 2015/9/21 19:13
#31
|
Just popping in
|
@djrikki
For MUI the same nesting depth restrictions as for Intuition apply, because eventually MUI must use Intution to handle the menus, no matter how they are initially created. As broadblues already pointed out this limit has been become void with the new menuclass, which MUI already tries to use if it is availble.
MUI's context menus have always been unlimited regarding the nesting depth.
|
|
|
|
|
|
Re: MUI text small & window fails to open if MUI_Text_Contents is too big
|
Posted on: 2015/8/21 19:47
#32
|
Just popping in
|
@ChrisH Quote: This sounds good in general... but it's gonna cause some confusion when testing MUI programs on AmigaOS4, and then later finding-out they look much worse with MUI3.x on AmigaOS3 (and other compatible) systems (including any old AmigaOS4.0 systems that haven't been updated!). Personally I'd have prefered such an improvement to be opt-in... You cannot make every single bit optional. That would make the MUI settings even more complex than they are already. Furthermore the default dimensions set during MUIM_AskMinMax are just a hint about how big the object wishes to become. If the desired dimensions exceeds the minimum/maximum dimensions it will be restricted accordingly. Finally MUI offers to snapshot the windows to make the layout/dimensions permanent. If one thinks the default sizes are bad it is no problem to adapt them and restore them for future uses. Quote: The only instance I could find/think-up, where it'd be a problem, was the get() method. OM_SET should also end up in DoSuperMethod(). Otherwise it will be impossible to modify any attributes of the parent class. Quote: I'd be interested to know which other methods/situations it could be a problem for... In general you can call DoSuperMethod() for any overridden method, unless you have very good reasons not to do so, i.e. if you want to replace the method's behaviour completely. If you class adds own custom methods then DoSuperMethod() of course is useless, because the parent class doesn't know the method and cannot do anything with it except passing it up to rootclass which eventually will do nothing than returning zero. To make it short: a waste of time.
|
|
|
|
|
|
Re: MUI text small & window fails to open if MUI_Text_Contents is too big
|
Posted on: 2015/8/17 9:48
#33
|
Just popping in
|
@ChrisH Quote: Quote:Setting MUIA_Text_SetMin to FALSE and MUIA_Text_SetMax to FALSE should do exactly what you want.
Unfortunately it does not, which has been my whole problem. It behaves as if the Text class does not modify the default width to take account of the initial text's width.
edit: If you have changed MUI behaviour in a recent version of MUI4, then it's possible I don't have that installed... however I would have assumed the default behaviour would be unchanged due to backwards-compatibility reasons. The initial behaviour of Text.mui was to modify the minimum and maximum width only and to leave the default width untouched. In January of this year I added a small change to set a default width of 3 "wide" characters to avoid invisible text labels by default. I guess this is the inconvenient behaviour you are experiencing right now. I just commited a change which sets the full text width as default width. This will let MUI make the window as wide as possible while still being able to cut off the text if its width exceeds the screen width. Quote: Don't worry, my MUI wrapper already does that automatically. Since it should always be called, it happens without me needing to remember such BOOPSI boilerplate Calling the superclass' method depends on what you want to archive. For certain methods the superclass' methed MUST be called (i.e. MUIM_Setup), but in certain other methods it is ok to skip the superclass' method (i.e. MUIM_Draw) if you are sure that this is ok and if you can ensure yourself that this doesn't cause any harm. Sometimes this is necessary, because otherwise superclass might do things which you definitely want to avoid to happen.
|
|
|
|
|
|
Re: MUI text small & window fails to open if MUI_Text_Contents is too big
|
Posted on: 2015/8/4 19:11
#34
|
Just popping in
|
@ChrisH
Setting MUIA_Text_SetMin to FALSE and MUIA_Text_SetMax to FALSE should do exactly what you want. SetMin serves to set either no minimum width (FALSE) or the text's maximum width as minimum width (TRUE). SetMax serves to set either no maximum label width (FALSE) or the text's maximum width as maximum label width (FALSE). Thus perhaps your own implementation should only restrict the minimum width to not let the label disappear completely.
If you really want to implement your own dimension calculation you can use MUI4's Area.mui method MUIM_TextDim. This has the advantage of respecting every detail MUI's text engine. Otherwise you are most probably restricted to plain texts only.
And regarding your example code, you really should not set the default width, but call the superclass' MUIM_AskMinMax method first and then add your own space requirements.
|
|
Why stop it now, just when I am hating it?
Thore Böckelmann
|
|
|
|
Re: MUI text small & window fails to open if MUI_Text_Contents is too big
|
Posted on: 2015/6/17 8:35
#35
|
Just popping in
|
@ChrisH Quote: What I don't understand is why the following behaviour is not the default for MUIC_Text (or at least be an option), since it's what I'd intuitively expect: The reasons are simple: 1. compatibility to older MUI versions 2. MUI just offers the basic functionality. If this is not enough for a specific case then it is your task to enhance the behaviour to match your requirements. MUI cannot guess everything. Completely vanishing text might be desired. If Text.mui would enforce an aribtrary amount of text to remain visible it would be impossible to revert this calculation in a subclass. Quote: The only thing I needed to do was to sub-class MUIC_Text so that it's MinMax method contained the following lines:
Quote: doSuperMethodA(cl, obj, msg)
msg.minmaxinfo.defwidth := msg.minmaxinfo.minwidth
msg.minmaxinfo.minwidth := 6
(That's AmigaE code, but the C equivalent should be fairly obvious.)
I did also add a New method to force MUIA_Text_SetMin to TRUE, since that's required by my code. But it's not strictly needed, since that's the default value.
The magic number "6" is what the Text class would otherwise have for minwidth, if MUIA_Text_SetMin was FALSE. Unfortunately I don't know how to calculate/deduce this, so it's hard-coded (if it causes problems then it would need to be increased). You definitely failed to read and understand the file MUIdev.guide. Please reread it from top to bottom, especially the section about the MUIM_AskMinMax method. It clearly states that the custom dimension values of your class are to be added, not just set. Adding is necessary, because at the time the MUIM_AskMinMax method reaches your class at least Area.mui (the superclass of Text.mui) and Text.mui already have added up their size requirements. Area.mui fills in any size requirements due a frame (frame size + spacing) and Text.mui fills in the size requirements due to the text size, depending on the values of MUIA_Text_SetMin/Max. Then it is your task to enlarge the sizes according to your class' personal requirements. The value 6 you are seeing is the summed up size requirement of your class' superclasses, namely Text.mui and Area.mui. Most probably you have set a visible frame. I'd guess it is a frame that is configured to have a frame size of 1 pixel plus a horizontal spacing of 2 pixels on both sides (or vice versa). Due to MUIA_Text_SetMin being FALSE Text.mui will add 0 to the minimum width in its MUIM_AskMinMax method. All this sums up to the value of 6. It is a bad idea to override this value by any other fixed artificial value, because this effectively makes the user's frame configuration void. In the worst case this might cause unwanted graphical corruption, because Text.mui's MUIM_Draw method might draw outside the desired area or at least it might ignore some certain frame spacing settings, because it doesn't know about your aritifically restricted minimum width. If you want a text object which is able to shorten its contents but which does not allow the text to become completely invisible, then all you need to do is to set MUIA_Text_SetMin to FALSE and add an arbitrary small value to MinMaxInfo->MinWidth to ensure that the object cannot become smaller than that size while a possible frame is still correctly respected with its size and spacing. For example something like this: Quote: DoSuperMethodA(cl, obj, msg);
msg->MinMaxInfo->MinWidth += 6; This will leave at least 6 pixels for the text to be displayed and will correctly respect any frame being set for the object. But I must add that such a fixed minimum size is still a bad idea, because depending on the user's font settings these artifical 6 pixels might still not be enough to display even a single character. MUI4 offers the MUIM_TextDim method to calculate the dimension of arbitrary strings depending on the object's font settings. The returned 32bit value contains the width in the lower 16 bits and the height in the upper 16 bits. The next nightly build of MUI4 will also contain the two DIM2WDTH/HEIGHT macros to extract the values in a convenient fashion. So better use MUIM_TextDim to calculate the width of a commonly fairly wide character (i.e. "W" or "M") and add the calculated width as the additional minimum width requirement within your MUIM_AskMinMax method: Quote: ULONG dim;
DoSuperMethodA(cl, obj, msg);
// calculate the dimension of the character "W" using the object's current font settings
dim = DoMethod(obj, MUIM_TextDim, "W", -1, NULL, 0);
msg->MinMaxInfo->MinWidth += DIM2WIDTH(dim); This will ensure that at least the widest character will remain visible while more narrow characters might fit.
|
|
|
|
|
|
Re: HIGHLIGHTTEXTPEN vs FILLPEN (difficulties colouring MUI text)
|
Posted on: 2015/6/15 7:38
#36
|
Just popping in
|
@ChrisH
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.
|
|
|
|
|
|
Re: HIGHLIGHTTEXTPEN vs FILLPEN (difficulties colouring MUI text)
|
Posted on: 2015/6/1 12:37
#37
|
Just popping in
|
@ChrisH Quote: 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.
|
|
|
|
|
|
Re: How to relay a varargs function?
|
Posted on: 2015/4/28 13:48
#38
|
Just popping in
|
@Deniil You need two functions in this case then: one for variable arguments and one with just one fixed argument. In every C runtime library you have something like fprintf() and vfprintf(). fprintf() is the vararg function while vfprintf() takes a single argument only (apart from the stream variable). Internally things are done like this:
void fprintf(FILE *stream, const char *format, ...)
{
va_list args;
va_start(args, format);
vfprintf(stream, args);
va_end(args);
}
void vfprintf(FILE *stream, va_list args)
{
// do all the necessary stuff with va_arg() here
}
|
|
|
|
|
|
Re: MUIdev.de
|
Posted on: 2015/1/22 10:53
#39
|
Just popping in
|
@djrikki
Replacing the battery is something that takes about one minute. Removing the case screws takes most of the time. But replacing a CR2032 battery is really no rocket science.
While we are at it and now that the vanishing button images issue from ticket #133 is fixed, would you please confirm whether ticket #132 is still valid? I asked you several times by now to provide a working (on AmigaOS3) Listtree demo, but all my recent requests went by unanswered/unnoticed and so far you uploaded non-working versions only.
|
|
|
|
|
|
Re: HIGHLIGHTTEXTPEN vs FILLPEN (difficulties colouring MUI text)
|
Posted on: 2015/1/21 10:49
#40
|
Just popping in
|
@ChrisH Quote: 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.
|
|
|
|
|
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
