I’m trying to improve the Mac GUi, I have again a working build env, I’m trying to figure all the changes that was made since the last time.
The GUI design part is almost done, need to bind the code now.
That sounds fantastic :-). How can I help? I'm happy to test stuff, for example.
And will it cause you any problems if I make a few more small changes to the Mac UI? I'd still like to try to make some of the changes that we've talked about recently, as well as fixing a few more minor bugs and trying to eliminate some compiler warnings. But I don't want to cause problems if you are making a bigger change.
Very little time.
Jerome
Envoyé de mon iPhone
> Le 13 sept. 2022 à 09:23, Nicolas Pomarède <npomarede@xxxxxxxxxxxx> a écrit :
>
> Le 12/09/2022 à 22:46, Eero Tamminen a écrit :
>> Hi Chris,
>> Sorry about that. I was hoping some other Mac user would try and comment on it. Or that Thomas would try & merge it as he has GitHub CI thingy for Mac builds.
>> (Even better would be review from somebody else who, unlike me, actually writes some Mac GUI code.)
>
> hi
>
> as we don't have many macOS coder here, maybe you can commit it and people will test the resulting macOS binary ; this is not as good as reviewing the source, but at least it will fix the IDE suffix issue for the users
>
> Nicolas
>
>
>>> On 12.9.2022 23.33, Chris Jenkins wrote:
>>> Hi,
>>>
>>> I realised we never did anything with this patch. Is it possible to merge
>>> it? I'm happy to receive any feedback on it as well.
>>>
>>> I might have a bit more timing in the coming weeks to make some of the
>>> other changes to the Mac UI that we have discussed but I wanted to get this
>>> one closed off first before I start trying to work on anything else.
>>>
>>> Cheers,
>>> Chris
>>>
>>>
>>>> On Sun, 28 Aug 2022 at 22:59, Chris Jenkins <cdpjenkins@xxxxxxxxx> wrote:
>>>
>>>> Hi,
>>>>
>>>> Attached is a second patch that removes the ability to specify file types
>>>> when specifying an existing file on disk (for example a disk image) in the
>>>> hopenfile() method, so we don't need to pass in `what:null` in several
>>>> places.
>>>>
>>>> It does _not_ remove the ability to specify file types when saving
>>>> something (like a memory snapshot) so it is still possible to cause the
>>>> user to _save_ a file of the desired type in the hsavefile() method.
>>>>
>>>> I didn't make any changes to the default directories, given Bob's comment
>>>> that he hopes that Hatari continues to save config files/screenshots in the
>>>> existing places.
>>>>
>>>> How does the above look?
>>>>
>>>> I'd be happy to make further changes to the Mac UI if needed but I need to
>>>> confess, once again, that I'm very much out of my comfort zone with
>>>> Objective C/Cocoa/Xcode so I'll need to see if I can find the time to learn
>>>> it a bit better. (For example, I promised you Eero that I would attempt to
>>>> add the ability to select MIDI files in the Mac GUI but didn't manage to
>>>> finish it at the time... I'd still like to find the time to do that.)
>>>>
>>>> Cheers,
>>>> Chris
>>>>
>>>>
>>>>
>>>> On Sat, 27 Aug 2022 at 00:42, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On 27.8.2022 0.20, Chris Jenkins wrote:
>>>>>>> * would NSOpenPanel default to all files being selectable i.e. could
>>>>>>> mutString lines be completely removed?
>>>>>>>
>>>>>>
>>>>>> It looks like it does. I'll remove the what: parameter completely,
>>>>> meaning
>>>>>> that the Mac GUI will allow any filetype to be specified in any file
>>>>>> selector. (As far as I understand it, that's what the SDL GUI does: no
>>>>>> matter what sort of file you are choosing, you can choose a file with
>>>>> any
>>>>>> extension. Correct me if I'm wrong on that one!)
>>>>>
>>>>> Yes, SDL GUI allows selecting any file, in any place where file is
>>>>> selected.
>>>>>
>>>>> (There's even support for select files inside Zip archive files.)
>>>>>
>>>>>
>>>>>> BTW, mutString will still be needed because that's used to return the
>>>>> path
>>>>>> of the chosen file.
>>>>>>
>>>>>> * does using this "chooseDirectories:NO defaultInitialDir" mean file
>>>>>>> selector defaulting to application workdir, or to dir of the initial
>>>>>>> file selection?
>>>>>>>
>>>>>>
>>>>>> I confess I haven't figured this out yet. I will attempt to figure it
>>>>> out
>>>>>> and report back. I confess that the file selector on the Mac sometimes
>>>>>> defaults to an unexpected place for me so it'll be good for me to
>>>>>> understand it better. I guess ultimately we'd want the Mac UI to behave
>>>>> the
>>>>>> same as the Hatari configuration defaults and/or the SDL UI...?
>>>>>
>>>>> Otherwise yes, but I guess it's fine to follow OS defaults for things
>>>>> like application (Hatari) configuration files, maybe also screenshots,
>>>>> if OS has defaults for such.
>>>>>
>>>>> (Although I have to admit that I like Hatari saving screenshots on Linux
>>>>> to working dir instead of my already full ~/Pictures/ folder.)
>>>>>
>>>>>
>>>>>> I'm busy this weekend but will attempt to create a new patch early next
>>>>>> week (once it works and I'm confident that I've not screwed up some
>>>>> basic
>>>>>> Objective C thing) to remove the filetype filters at least.
>>>>>
>>>>> Great, thanks!
>>>>>
>>>>>
>>>>> - Eero
>>>>>
>>>>>
>>>>>
>>>
>
>
>