helloSystem / Artwork

Other
0 stars 1 forks source link

Need a generic application icon #2

Open probonopd opened 1 year ago

probonopd commented 1 year ago

Instead of

image

we need soemething in this style

image image

or in this style

image

so that it can immediately be recognized as being an application.

PaulMcClernan commented 1 year ago

OK, will try to work on variations tonight or this weekend. I'm currently building new a OpenXTalk AppImage.

Off topic: What desktop/file manager is 'Filer' based on? Files (Nautilus)? Is helloSystems combined File-manger & DE based on Pantheon or what? I want to try editing some of the key-combos.

I just installed Elementary OS on my sons old-old ASUS zen netbook-thing (circa 2016, I think?), and the latest stable release runs very well, considering that it's only DualCore 1.6 ghz Celeron with integrated graphics and only 2GB of ram! Their Pantheon DE may be the most Mac-like experience I've ever had outside of macOS. I changed a few keyboard shortcuts and I almost forgot I was not on macOS! As a MacAddict since about 1987, I should really make notes on when somethings I'm expecting is missing from a mac-like experience, could be useful for both elementaryOS and helloSystem. For example command+w closes a window, easy enough, but command+option+w to close ALL of the File manager windows is something I'm always missing on *nix desktops. Option key combo modifiers work with lots for Finder things. For other examples option+clicking-minimize-window-button minimizes ALL Finder windows, command+up-arrow opens a window for it's parent directory but command+option+up-arrow opens a window for it's parent directory AND closes the child-window / current directory, option+disclosure triangle reveals ALL options, there are many examples. These are some of little things that have made macOS 'insanely great' IMO, fast graphical file / window management using key combos. And Consistency, try those in the finder and they work with their System 7 equivalent from three decades ago.

probonopd commented 1 year ago

What desktop/file manager is 'Filer' based on?

It started out as a ork of an older version of PCManFM-Qt but has gone its own ways for a while now.

As a MacAddict since about 1987, I should really make notes on when somethings I'm expecting is missing from a mac-like experience, could be useful for both elementaryOS and helloSystem. For example command+w closes a window, easy enough, but command+option+w to close ALL of the File manager windows is something I'm always missing on *nix desktops.

Yes, I'd like to hear about thse things! Would help the project a lot. But each in its own GitHub Ticket please.

command+up-arrow opens a window for it's parent directory but command+option+up-arrow opens a window for it's parent directory AND closes the window current window.

Command-Shift-Up should work in helloSystem.

louies0623 commented 1 year ago

image https://elementary.io/docs/learning-the-basics#keyboard-shortcuts

louies0623 commented 1 year ago

The above hand does not have the correct perspective, it should look like this

image

probonopd commented 1 year ago

Yes, but rotated by 90 degrees to the right.

PaulMcClernan commented 1 year ago

GenericApp4symbolic

GenericApp4symbolic-32px GenericApp4-32px

GenericApp4

PaulMcClernan commented 1 year ago

Sorry to go OT again but I've been wrestling with making this OXT AppImage. it mostly works normally, the only thing broken is OXT runtime ability to dynamically load libraries (it has extensibility, makes bytecode, and like Python it can use libFFI), at least not from within the .AppImages filesystem (which doesn't always appear in the File browsing, although obviously Fuse mounted it) Specifically my OXT FluidSynth wrapper can't load libFluidSynth when asked to. I believe I have the all dependencies in there and executable permissions set. Maybe I need to add some RPATH= for my extensions directories to the AppImage loading process? I could use some advice, and you're the AppImage guy right? Or are you not working on that anymore?

probonopd commented 1 year ago

Please make sure that your QXT is loading these things from a path that is calculated by QXT relative to itself. AppImages get mounted at ever-changing locations in the filesystem.

PaulMcClernan commented 1 year ago

Please make sure that your QXT is loading these things from a path that is calculated by QXT relative to itself. AppImages get mounted at ever-changing locations in the filesystem.

Yes I'm noticing that now, that string of random chars in the named mount point, but I believe the toolchain it includes should load it lib relative to the extension module, which is in one of the IDEs sub-directories, but I'll have to double check how the loader finds its modules path wise. Perhaps there's some environmental variable set by AppImage runtime that I could read to get the mount points name once OXT engine is running? I'm going to do some testing / tinkering with it now, I should be able to compile a module from my desktop / mutable local storage outside of the AppImage and install it to the user's App storage directory (OXT has a package manager of sorts).

probonopd commented 1 year ago

$APPDIR. But please let'S have this discussion elsewhere, as helloSystem != AppImage.

PaulMcClernan commented 1 year ago

$APPDIR

Thanks! I did some more tests and I am getting correct posix paths, and I was able to load Hunspell wrapper and lib.so just fine so the issue might not even be AppImage related.

But please let'S have this discussion elsewhere, as helloSystem != AppImage.

Agreed, where is good for discussion of AppImage?