GNUstep Build Guide
Hi gnusteppers, After some years not playing with it, I am trying to setup a new linux environment with GNUstep and I got lost with the different guides and repositories, I hope this is the right place to ask for some support. My goal is to build it from source, so that I can also try to contribute. If possible I would like to use an ubuntu image as base. In case you think Ubuntu is not the best base image, please feel free to suggest a different setup. Where would it be the best place to look to get started? thanks, Riccardo
Re: GNUstep Build Guide
Hi thanks for the info! I tried the scripts and read some of the sources to understand better and i’ve got it working! Now i’ll dig a bit into the libraries and probably will come back with more problems :) thanks Riccardo On Wed 15. Sep 2021 at 23:12, Patryk Laurent wrote: > Hi Riccardo, > > Here are some scripts some of us use to build from source, including under > Ubuntu. > > https://github.com/plaurent/gnustep-build > > In particular see: > > > https://github.com/plaurent/gnustep-build/tree/master/ubuntu-20.10-clang-11.0-runtime-2.0 > > Best, > Patryk > > > On Sep 15, 2021, at 00:00, Riccardo Canalicchio < > riccardo.canalicc...@gmail.com> wrote: > > > > Hi gnusteppers, > After some years not playing with it, I am trying to setup a new linux > environment with GNUstep and I got lost with the different guides and > repositories, I hope this is the right place to ask for some support. > > My goal is to build it from source, so that I can also try to contribute. > If possible I would like to use an ubuntu image as base. In case you think > Ubuntu is not the best base image, please feel free to suggest a different > setup. > > Where would it be the best place to look to get started? > > thanks, > Riccardo > >
Wayland backend
Hi, I played a bit with the wayland backend trying to make it work. Here is a branch where I made some changes on the surface management and reimplemented the xdg toplevel to send the surfaces to the server only when they should be visible. https://github.com/nongio/libs-back/commit/c6ce795898d0d71afa9dbe165ae9ff99e90bc8d2 Right now the rendering seems correct. Even though the windows are still getting stuck after some time showing the loading cursor, it is possible to make some interactions. It also needs some memory management, listening at when the memory buffers can be deleted. Feedback on this work is welcome, as well I am happy to onboard anyone interested in the approach. best, Riccardo
Re: Wayland backend
sure, in wayland when creating a popup window is requested to provide a parent window. When creating a window for a submenu, I had to find a way to retrieve the window of the parent menu, what the code does is: 1) get a NSWindow from windowid 2) get the NSMenu associated 3) get supermenu from the menu 4) get the window from the supermenu to access the NSWindow [instance menu] I had to expose the attribute previously private. Here the change https://github.com/gnustep/libs-gui/pull/122/files cheers, Riccardo On Sun, 7 Nov 2021 at 21:23, Fred Kiefer wrote: > Great improvement! Thank you for that. > > > Am 06.11.2021 um 13:33 schrieb Riccardo Canalicchio < > riccardo.canalicc...@gmail.com>: > > > > Hello, > > following up on this, I moved forward with the implementation and I have > got to a working state. (with still some bugs but usable) > > Windows are shown properly, dropdown menus as well, resize and move work. > > The implementation is tested on Weston, GnomeShell and some other > compositors based on wlroots. It uses the protocol xdgshell widely adopted > in all the compositors as well the layer shell protocol which is currently > adopted by the wlroots compositors and ubuntu shell. > > Here a PR: https://github.com/gnustep/libs-back/pull/33 > > > > note: To be able to associate submenus to the parent windows i had to > make a change to libs-gui: > > > https://github.com/nongio/libs-back/blob/wayland/Source/wayland/WaylandServer.m#L894 > > maybe there are better ways to do it, in case you think it's ok i would > proceed to make a PR for libs-gui too > > Could you please explain this a bit? What is the issue here and what is > your workaround? And what could be a better workaround in gui? > > Cheers, > Fred
Re: Wayland backend
Hello! I made some more progress, I implemented cairo-egl surfaces for the wayland backend, this should make things snappier (at least it works way better in my VM) Given that the previous PR is quite complex already, I'd suggest to keep these changes separated for now, here you can take a look: https://github.com/nongio/libs-back/pull/1 If you want to try it out, the branch is "wayland-egl": https://github.com/nongio/libs-back/tree/wayland-egl To be able to use it, you will need a version of cairo with EGL support and surface backend: OpenGL ES 2.0, here a gist of the modified meson_options.txt to compile it yourself: https://gist.github.com/nongio/e0365186b867d85c4092c6c3d9e998cc If you are interested i am available to have a session where i can explain the approach, cheers, Riccardo On Sun, 7 Nov 2021 at 21:37, Riccardo Canalicchio < riccardo.canalicc...@gmail.com> wrote: > sure, in wayland when creating a popup window is requested to provide a > parent window. > When creating a window for a submenu, I had to find a way to retrieve the > window of the parent menu, what the code does is: > 1) get a NSWindow from windowid > 2) get the NSMenu associated > 3) get supermenu from the menu > 4) get the window from the supermenu > > to access the NSWindow [instance menu] I had to expose the > attribute previously private. Here the change > https://github.com/gnustep/libs-gui/pull/122/files > > cheers, > Riccardo > > > On Sun, 7 Nov 2021 at 21:23, Fred Kiefer wrote: > >> Great improvement! Thank you for that. >> >> > Am 06.11.2021 um 13:33 schrieb Riccardo Canalicchio < >> riccardo.canalicc...@gmail.com>: >> > >> > Hello, >> > following up on this, I moved forward with the implementation and I >> have got to a working state. (with still some bugs but usable) >> > Windows are shown properly, dropdown menus as well, resize and move >> work. >> > The implementation is tested on Weston, GnomeShell and some other >> compositors based on wlroots. It uses the protocol xdgshell widely adopted >> in all the compositors as well the layer shell protocol which is currently >> adopted by the wlroots compositors and ubuntu shell. >> > Here a PR: https://github.com/gnustep/libs-back/pull/33 >> > >> > note: To be able to associate submenus to the parent windows i had to >> make a change to libs-gui: >> > >> https://github.com/nongio/libs-back/blob/wayland/Source/wayland/WaylandServer.m#L894 >> > maybe there are better ways to do it, in case you think it's ok i would >> proceed to make a PR for libs-gui too >> >> Could you please explain this a bit? What is the issue here and what is >> your workaround? And what could be a better workaround in gui? >> >> Cheers, >> Fred > >
Emoji support in textfields
Hello, I am wondering if anyone would be interested in having support for emojis in libs-gui 🤓 How complicated would it be? I think cairo already should be able to render them: https://www.phoronix.com/scan.php?page=news_item&px=Cairo-1.15.8-Colored-Emoji cheers, Riccardo
Re: Emoji support in textfields
Yes! Unicode and something like Noto emoji font [1] should do the job, this is the best description that I have found on how emojis work [2] I think that the complicated part is to let the rendering swap between current font and emoji font recognising when a glyph it's an emoji, the ICU library should be the right tool for that [3] As well here a simple example that shows how to get the glyphs and then render with the specific font in cairo [4] cheers Riccardo [1] https://github.com/googlefonts/noto-emoji [2] https://tonsky.me/blog/emoji/ [3] https://icu.unicode.org/ [4] https://github.com/rozaxe/ex-harfbuzz-sdl2-cairo-freetype-emoji/blob/master/main.c On Tue, 16 Nov 2021 at 00:49, Riccardo Mottola wrote: > Hello namesake, > > Riccardo Canalicchio wrote: > > I am wondering if anyone would be interested in having support for > > emojis in libs-gui 🤓 > > absolutely not ;-) > > However both GNUmail and TalkSoup have am emoticon plugins - but it is > not exactly emoji: it is old-school replacement of text with icons, so > it is backend independent and font independent. So more of those > phone-style icons are missing, since they don't have a direct text > representation. > > I suppose more you want to use unicode and specific fonts? > > Riccardo > >
Re: Dock app using distributed objects
thanks for the feedback, it is really appreciated, the idea of DO came from looking at the osx api for the NSStatusBar [1] ideally one could have something like: [[Dock systemDock] registerDockTile: dockTileView]; [dockTileView setTitle:@"My app name"]; [dockTileView setMenu:menu]; ... [dockTileView setBadgeLabel:@"4"]; I did evaluate different approaches less invasive from the "client" point of view but they would require different implementations based on the backend in use and would lead to different results. This is because they would need to reparent the mini windows to the dock. On Xorg this could be achieved using Xembed [2] (kde used to have something like this) while on wayland with the XDG foreign protocol (unstable atm) [3]. In the end, I opted for DO mainly because it could be implemented entirely in gnustep, it would be consistent across backends and would provide all the features I would expect from a dock as well the possibility to render the tiles in a cohesive way. To make the dock registration optional for apps and support non-gnustep applications the dock could have a mechanism to automatically generate dock tiles listening to the running processes and then allow through the api to customise the appearance and the menu. Contributions also in the form of suggestions are more than welcome :D best regards, Riccardo [1] https://github.com/tjarratt/NSStatusItemExample/blob/master/NSStatusItemExample/AppDelegate.m [2] https://specifications.freedesktop.org/xembed-spec/xembed-spec-latest.html [3] https://wayland.app/protocols/xdg-foreign-unstable-v2 On Tue, 7 Dec 2021 at 11:08, Richard Frith-Macdonald < rich...@frithmacdonald.me.uk> wrote: > > > > On 7 Dec 2021, at 08:48, Gregory Casamento > wrote: > > > > Riccardo, > > > > Firstly, the dock is visually appealing, full marks. :) > > > > > > On Mon, Dec 6, 2021 at 3:03 PM Riccardo Canalicchio < > riccardo.canalicc...@gmail.com> wrote: > > Hello, > > I have been thinking about how to have a live image representation of an > app for a dock application and I wanted to try with distributed objects. > > > > But, secondly, I believe there is another, more lightweight, way that > can be used to do this aside from DO. The issue I see here is requiring > every app to do it this way. If you look in NSApplication you will see a > reference to NSIconView and NSIconWindow. These classes display the > changing icon in WindowMaker (this is not an endorsement of wmaker, I would > like a GS based Dock outside of GWorkspace as well). So, perhaps, it is > possible to do this without using Distributed Objects. This is only a > suggestion, I like where you're going. > > Yes ... I remmber from many, many years ago (way back when I was working > on the GUI) I had this working as it worked in NeXTstep: the miniwindow > used to be a fully functional window that a NeXTstep app could write into > while it is in the dock. This was used to create visual indicators, in the > dock, of the state of an application. > > I also recall being annoyed because Apple removed this functionality from > OSX and replaced it with a different mechanism (much more limited and less > technically satisfying, but a simpler way to achieve a similar effect in > practice), though I don't recall the details. I'm pretty sure we moved to > match the OSX implementation. I expect this is what WindowMaker is working > with. > > >
Re: GNUstep on Hackernews
What about using github automations for building the packages? I am not sure but i think we could also use github pages for hosting, i found a tutorial on how to set it up but it's from 2017 not sure if it's still valid: https://pmateusz.github.io/linux/2017/06/30/linux-secure-apt-repository.html Best, Riccardo On Fri, 17 Dec 2021 at 12:34, Andreas Fink wrote: > I can set up another repository server for it easily. > I have my own hosting service so hardware is not an issue. > > The question is also how often new packages should be built and how the > releases should be streamlined. > This is more an organisational question than a technical one. > > Best would be if this could be automated in nightly builds or so. But > this means writing a lot of scripts to catch any errors etc. > Anyone has experience with this? > > > H. Nikolaus Schaller wrote on 17.12.21 11:35: > > > >> Am 17.12.2021 um 11:19 schrieb Andreas Fink : > >> > >> > >> > >> H. Nikolaus Schaller wrote on 17.12.21 10:57: > Am 17.12.2021 um 10:33 schrieb Andreas Fink : > > packages in Debian are quite old and don't support objc2.0. So they > are > not suitable for new development. > I always build my own packages due to that. > >>> That is why I propose the idea to provide a separate, maintained > repository outside of debian.org > >>> but compatible to it... > >>> > >>> People just > >>> 1. add some /etc/apt/sources.list.d/gnustep.conf to e.g. > deb.gnustep.org (see https://wiki.debian.org/DebianRepository) > >>> 2. download and install some GPG key > >>> 3. then apt-get update > >>> 4. and apt-get install gnustep > >>> 5. later apt-get upgrade > >>> > >>> Same can be done for Ubuntu. > >>> > >>> So if you already build your own packages, why not publish them in > such a repo? Incl. objc2.0? > >> it is public already. I use it heavily in my ulib library and all > >> libraries based on top of it (such as universalss7). > >> > >> Add the repo key: > >> > >> wget -4 -O - http://repo.universalss7.ch/debian/key.asc |apt-key > add - > >> or > >> apt-key adv --recv-keys --keyserver keyserver.ubuntu.com > >> EE85CFC98EC405E3115EE86BD173212BFB27007D # UniversalSS7 > >> > >> add the repository to your /etc/apt/sources.list > >> > >> Debian10 > >> deb http://repo.universalss7.ch/debian/ buster universalss7 > >> > >> Debian 11 > >> deb http://repo.universalss7.ch/debian/ bullseye universalss7 > >> > >> I can built for Intel and arm64 > >> I also built one for Ubuntu a while back. > >> Not much difference. > >> > >> The versions in my repo are built for my own use and thus are installed > >> in /usr/local/ to not interfer with anything installed from other > sources. > > Good! > > > >> I can build a release version for debian 10 or 11 if I know how the > >> original packages where built. > >> (what config otions etc) > > That is nice!!! > > > > So we would just need some deb.gnustep.org forwarding so that the > > real repo location can be switched easily... > > > Btw who is the Debian maintainer for the gnustep builds? > >>> In my proposal it could be a member of the GNUstep community so we > don't have to wait > >>> for someone from Debian core... > >> I agree but "someone from Debian core" must be someone who built it > >> originally. The config of these builds is what interests me. > > Ok, that can be found out through e.g. (same scheme for all other > packages): > > > > https://packages.debian.org/bullseye/gnustep-make > > > > There is a Maintainer list on the rightmost column. > > It mentions an e-mail address: > pkg-gnustep-maintain...@lists.alioth.debian.org > > > > And you can also download the files gnustep-make_2.8.0-1.dsc etc. which > includes the config used for compilation. > > > > Or alternatively apt-get the source package and look inside how Debian > would build from source. > > > > BR, > > Nikolaus > > > > > > > >
Re: ANN: GWorkspace 1.0
thanks for the work on GWorkspace and congratulations on the release!! merry xmas and happy new year, Riccardo On Sat 25. Dec 2021 at 02:34, Riccardo Mottola via Info-gnustep < info-gnus...@gnu.org> wrote: > GWORKSPACE 1.0 > -- > > Christmas, in Anno Domini 2021. > > This is a different announcemement than usual, since it is a special > release: it is tagged 1.0 after many years of work. It is different, > because it is a personal writing. The last release has been long ago, > but many refinements and improvements came in; there has been a person > who spurred me improving and working on GWorkspace: Bertrand > Dekoninck. > > Hard times were the past two years and they have not been easy and the > pandemic is not yet over, so in the Christmas Eve, a new release of > GWorkspace has been done and it is dedicated to Bertrand: so shall he > be remembered from us GNUsteppers, he, who had not the privilege to > live till Christmas with his family. > > A reserved user who really gave the sensation to be interested in > GNUstep and its applications, thus, especially GWorkspace. > Continuously he proposed contributions, tested, always gentle, > collaborative: a friend. I will miss him, we will miss him. > Betrand, as me, worked also on PowerPC - so it was inspiring to know > that supporting that Big Endian platform was useful! After the > pandemic, I wanted to meet hi8mfor a hacking session, but it will no > longer happen on earth. > > Merry Christmas and a Happy New Year! > > > Riccardo > > > What is new? > > * "Modern mode" enables now clearer icon lables on the desktop > * Single click launch is now an option and affects the Dock and the > Tabbed shelf > * cleaned up code in Shelf and Dock Icons > * Fixed display of available tools for documents in the inspector > * Improved display of handled extensions for an applications > * Improve image scaling for image content inspector and image > thumbnailer > * Better handling of removable volumes > * Improved French, Italian and Spanish localizations, as well as new > Japanese and Polish ones > * The build system was improved and cleaned up, allowing easier > packaging and building on different platforms > * Fix crash in Metadata extractor > * Fix build failure on GNU/HURD > > Links for info and downloads: > > http://www.gnustep.org/experience/GWorkspace.html > http://www.gnustep.org/resources/downloads.php > https://github.com/gnustep/apps-gworkspace > > -- > Sent with GNUMail on GNUstep on Gentoo running on a ThinkPad T510i-i5. > > > ___ > Info-gnustep mailing list > info-gnus...@gnu.org > https://lists.gnu.org/mailman/listinfo/info-gnustep >
Re: Kickstarter was not successful... but it did help things...
Hi all, please to meet you, and thanks for your work on gnustep. Sorry for the intrusion into the discussion... I'm Riccardo Canalicchio, a fresh new gnustep user, I would like to be involved in the development. I'm studying the gnustep environment and currently I'm trying to make a a theme because I don't feel confortable with the default. When the theme will be in a usable stage I'd like to share it with you. Meanwhile if I've some doubts is this mailing list the right place to have some mentoring? On 23 November 2013 12:33, Richard Frith-Macdonald < richardfrithmacdon...@gmail.com> wrote: > > On 23 Nov 2013, at 08:48, Gregory Casamento > wrote: > > > I'm in agreement with this. I've been saying this for many years. I > would like to call for a consensus on this matter. Are there any dissenting > opinions to changing the default look? > > Yes! > > Show me the theme you want to switch to, and then we can talk about it > (I'm easily persuaded if something makes sense). I would have thought that > an iOS style theme might be popular. > But until we have at least one fully working alternative theme to switch > to (or better, a number of themes to select from), discussing switching is > nothing but a waste of time. > > Actually, even the argument that the *default* theme puts people off is > really nonsense ... if people see something that puts them off, is is what > they *see* that puts them off, not whether what they see is *default*. > > Put screenshots of GNUstep looking 'sexier' on the website. Make them > more prominent than the existing theme by all means (eg. put them first and > bigger). To find out which works best (ie is most popular) we could have > some sort of click-through or download counter. > > I've just been reading a book 'Thinking, Fast and Slow' by Daniel Kahneman > and one of the things I was struck by was the psychological research > measuring the tendency of people to avoid risk to the extent of avoiding > changes from an existing state even when, in any other context, they would > think the new sytate was better than the old one. > > Whatever you intend, as long as you talk about changing the default theme, > people will read that as replacing/getting-rid-of the current look (rather > than supporting equal alternatives). While I know that's not what you > mean, it's counterproductive as it will always produce opposition from > anyone who likes the current theme, and even from people who might like a > new theme better! IMO you should simply provide/advertise at least one > good new look rather than 'threatening' a change. > > Build and advertise at least one good new theme. > > 'If you build it, he will come' > ___ > Discuss-gnustep mailing list > Discuss-gnustep@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
NSgradient bug
hi there, i'm unable to draw a gradient clipped by a bezierpath. I'm trying to fill a roundeded rectangle path with a gradient here you can see the code that i'm using to draw: https://github.com/nongio/gs-testDrawing I don't know if it is a cairo backend problem or a NSGradient bug... I managed to get it works changing drawInBezierPath method of NSGradients: [currentContext saveGraphicsState]; [path addClip]; [self drawInRect: [path bounds] angle: angle]; [currentContext restoreGraphicsState]; I have changed drawInRect with drawFromPoint:toPoint ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
porting a framework to gnustep
Hi, I'm trying to port a framework to gnustep. The framework is OCDiscount parser, it's an obj-c wrapper around the discount library used for markdown parsing. here the source code: https://github.com/nongio/ocdiscount I'm using pbxbuild over the xcodeproj file without success... is there a tutorial or a guide to frameworks bundles in GNUstep? ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: porting a framework to gnustep
ok, thanks a lot, I will try the builtool way and I will let you know thanks On 2 December 2013 14:53, Gregory Casamento wrote: > Under dev-libs there is a framework called "xcode" build that and install, > then build "buildtool" located under dev-apps. buildtool is a replacement > for pbxbuild which directly interprets the xcodeproj file instead of > clumsily trying to convert it into makefiles. Let me know if you have any > success with this. > > To directly answer your question, there is no set way to do this. It > always depends on what your application/tool/framework/etc requires. > Typically there are missing components (such as Core* frameworks and etc) > but I don't believe that's a problem in your case. > > Greg > P.S. pbxbuild as it is currently is unofficially deprecated. You should > certainly try buildtool. > > > On Mon, Dec 2, 2013 at 8:39 AM, Riccardo Canalicchio < > riccardo.canalicc...@gmail.com> wrote: > >> Hi, >> I'm trying to port a framework to gnustep. >> The framework is OCDiscount parser, it's an obj-c wrapper around the >> discount library used for markdown parsing. >> >> here the source code: >> https://github.com/nongio/ocdiscount >> >> I'm using pbxbuild over the xcodeproj file without success... is there a >> tutorial or a guide to frameworks bundles in GNUstep? >> >> ___ >> Discuss-gnustep mailing list >> Discuss-gnustep@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >> >> > > > -- > Gregory Casamento > Open Logic Corporation, Principal Consultant > yahoo/skype: greg_casamento, aol: gjcasa > (240)274-9630 (Cell) > http://www.gnustep.org > http://heronsperch.blogspot.com > ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: porting a framework to gnustep
buildtool gave me errors so I tried to write a GNUmakefile manually, I have updated the repository: https://github.com/nongio/ocdiscount here the GNUmakefile: https://raw.github.com/nongio/ocdiscount/master/GNUmakefile now it builds without errors On 2 December 2013 15:36, Riccardo Canalicchio < riccardo.canalicc...@gmail.com> wrote: > ok, thanks a lot, I will try the builtool way and I will let you know > > thanks > > > On 2 December 2013 14:53, Gregory Casamento wrote: > >> Under dev-libs there is a framework called "xcode" build that and >> install, then build "buildtool" located under dev-apps. buildtool is a >> replacement for pbxbuild which directly interprets the xcodeproj file >> instead of clumsily trying to convert it into makefiles. Let me know if >> you have any success with this. >> >> To directly answer your question, there is no set way to do this. It >> always depends on what your application/tool/framework/etc requires. >> Typically there are missing components (such as Core* frameworks and etc) >> but I don't believe that's a problem in your case. >> >> Greg >> P.S. pbxbuild as it is currently is unofficially deprecated. You should >> certainly try buildtool. >> >> >> On Mon, Dec 2, 2013 at 8:39 AM, Riccardo Canalicchio < >> riccardo.canalicc...@gmail.com> wrote: >> >>> Hi, >>> I'm trying to port a framework to gnustep. >>> The framework is OCDiscount parser, it's an obj-c wrapper around the >>> discount library used for markdown parsing. >>> >>> here the source code: >>> https://github.com/nongio/ocdiscount >>> >>> I'm using pbxbuild over the xcodeproj file without success... is there a >>> tutorial or a guide to frameworks bundles in GNUstep? >>> >>> ___ >>> Discuss-gnustep mailing list >>> Discuss-gnustep@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >>> >>> >> >> >> -- >> Gregory Casamento >> Open Logic Corporation, Principal Consultant >> yahoo/skype: greg_casamento, aol: gjcasa >> (240)274-9630 (Cell) >> http://www.gnustep.org >> http://heronsperch.blogspot.com >> > > ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: porting a framework to gnustep
attached the build output, seems that the main problem is that it doesn't find a diretory... On 2 December 2013 22:36, Gregory Casamento wrote: > "gave you errors"? > > Could you elaborate so I can debug? > > Greg > > > On Mon, Dec 2, 2013 at 4:34 PM, Riccardo Canalicchio < > riccardo.canalicc...@gmail.com> wrote: > >> buildtool gave me errors so I tried to write a GNUmakefile manually, I >> have updated the repository: >> >> https://github.com/nongio/ocdiscount >> >> here the GNUmakefile: >> https://raw.github.com/nongio/ocdiscount/master/GNUmakefile >> >> now it builds without errors >> >> >> >> >> >> >> >> On 2 December 2013 15:36, Riccardo Canalicchio < >> riccardo.canalicc...@gmail.com> wrote: >> >>> ok, thanks a lot, I will try the builtool way and I will let you know >>> >>> thanks >>> >>> >>> On 2 December 2013 14:53, Gregory Casamento wrote: >>> >>>> Under dev-libs there is a framework called "xcode" build that and >>>> install, then build "buildtool" located under dev-apps. buildtool is a >>>> replacement for pbxbuild which directly interprets the xcodeproj file >>>> instead of clumsily trying to convert it into makefiles. Let me know if >>>> you have any success with this. >>>> >>>> To directly answer your question, there is no set way to do this. It >>>> always depends on what your application/tool/framework/etc requires. >>>> Typically there are missing components (such as Core* frameworks and etc) >>>> but I don't believe that's a problem in your case. >>>> >>>> Greg >>>> P.S. pbxbuild as it is currently is unofficially deprecated. You >>>> should certainly try buildtool. >>>> >>>> >>>> On Mon, Dec 2, 2013 at 8:39 AM, Riccardo Canalicchio < >>>> riccardo.canalicc...@gmail.com> wrote: >>>> >>>>> Hi, >>>>> I'm trying to port a framework to gnustep. >>>>> The framework is OCDiscount parser, it's an obj-c wrapper around the >>>>> discount library used for markdown parsing. >>>>> >>>>> here the source code: >>>>> https://github.com/nongio/ocdiscount >>>>> >>>>> I'm using pbxbuild over the xcodeproj file without success... is there >>>>> a tutorial or a guide to frameworks bundles in GNUstep? >>>>> >>>>> ___ >>>>> Discuss-gnustep mailing list >>>>> Discuss-gnustep@gnu.org >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >>>>> >>>>> >>>> >>>> >>>> -- >>>> Gregory Casamento >>>> Open Logic Corporation, Principal Consultant >>>> yahoo/skype: greg_casamento, aol: gjcasa >>>> (240)274-9630 (Cell) >>>> http://www.gnustep.org >>>> http://heronsperch.blogspot.com >>>> >>> >>> >> >> ___ >> Discuss-gnustep mailing list >> Discuss-gnustep@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >> >> > > > -- > Gregory Casamento > Open Logic Corporation, Principal Consultant > yahoo/skype: greg_casamento, aol: gjcasa > (240)274-9630 (Cell) > http://www.gnustep.org > http://heronsperch.blogspot.com > ocdiscount_buildtool.log Description: Binary data ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
flicker graphics on window resize
hi all, I'm experiencing a very annoying bug: during the resize of a window, the graphic rectangle occupied by the window starts to flicker until the resize is done. When I say flicker I mean that the window content is displayed before It is completely drawn. I'm using the cairo backend. Is this the default behaviour or I missed some configuration steps? ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: flicker graphics on window resize
yes, I'm using GNUstep from SVN, someone is already working on this problem? If not, I would like to try to find a solution... Could someone please give me some hints to start investigate the problem? On 17 December 2013 07:35, Germán Arias wrote: > Hi, > > I suppose this is with GNUstep from SVN, right? I'm having the same > problem. The window show a black rectangle, that don't fit the window, > while I resize the window. This is not obvious in WindowMaker since, by > default, WM use a "phantom" resize. But if I change this at defaults, I > notice > this problem. However, as far as I remember, the ugly flickering as been > there always. > > Germán > > On 2013-12-16 12:38:28 -0600 Riccardo Canalicchio < > riccardo.canalicc...@gmail.com> wrote: > > > hi all, > > I'm experiencing a very annoying bug: during the resize of a window, the > > graphic rectangle occupied by the window starts to flicker until the > resize > > is done. > > When I say flicker I mean that the window content is displayed before It > is > > completely drawn. > > I'm using the cairo backend. Is this the default behaviour or I missed > some > > configuration steps? > > ___ > > Discuss-gnustep mailing list > > Discuss-gnustep@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > > > > ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: flicker graphics on window resize
Hi Fred and thank you for your hint, I'm doing some debugging to see what happen on resize but It's not simple for me to understand the logic behind. Currently I'm on IRC (freenode#gnustep nickname: nongio) if anyone would like to talk about this issue I would appreciate a lot! On 17 December 2013 22:34, Fred Kiefer wrote: > You are welcome to look into this. Yesterday I tried to use valgrind > (callgrind in this case) to detect any anomalies, but couldn't spot any > big performance change to previous versions. > > I also made a quick check and the problem shows up with the cairo and > the art backend, but not with the xlib one. This points in the direction > of the shared class XWindowBuffer, but that class no longer gets used by > the modern cairo implementation in GNUstep. There XGCairoModernSurface > gets used. > > My feeling is that the X server tries to draw the window contents while > we haven't properly set up the surface to draw it. But this might be > completely off. > > Sorry to be of so little help, > Fred > > On 17.12.2013 10:10, Riccardo Canalicchio wrote: > > yes, I'm using GNUstep from SVN, someone is already working on this > > problem? > > If not, I would like to try to find a solution... Could someone please > give > > me some hints to start investigate the problem? > > > > On 17 December 2013 07:35, Germán Arias wrote: > > > >> Hi, > >> > >> I suppose this is with GNUstep from SVN, right? I'm having the same > >> problem. The window show a black rectangle, that don't fit the window, > >> while I resize the window. This is not obvious in WindowMaker since, by > >> default, WM use a "phantom" resize. But if I change this at defaults, I > >> notice > >> this problem. However, as far as I remember, the ugly flickering as been > >> there always. > >> > >> Germán > >> > >> On 2013-12-16 12:38:28 -0600 Riccardo Canalicchio < > >> riccardo.canalicc...@gmail.com> wrote: > >> > >>> hi all, > >>> I'm experiencing a very annoying bug: during the resize of a window, > the > >>> graphic rectangle occupied by the window starts to flicker until the > >> resize > >>> is done. > >>> When I say flicker I mean that the window content is displayed before > It > >> is > >>> completely drawn. > >>> I'm using the cairo backend. Is this the default behaviour or I missed > >> some > >>> configuration steps? > > > ___ > Discuss-gnustep mailing list > Discuss-gnustep@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: flicker graphics on window resize
no problem Fred, tell me If I'm right: - when using a buffered window there should be two cairo surfaces (back and front) - a window resize, trigger the re initialisation of all the two surfaces - actually the fresh new surfaces get drawn immediatly (in my case they are white) I think that there should be always a surface drawble, this mean that we should reallocate the surfaces one at a time. what do you think? On 20 December 2013 10:12, Fred Kiefer wrote: > Hi Riccardo, > > sorry, I don't do IRC and was away last night. > > What happens on resize is that we have to regenerate the backend surface > all the time. And most likely we are copying over uninitialized data. Or > not drawing at all. The interesting question is who is drawing the black in > between? > > Fred > > On the road > > Am 19.12.2013 um 20:01 schrieb Riccardo Canalicchio < > riccardo.canalicc...@gmail.com>: > > Hi Fred and thank you for your hint, > I'm doing some debugging to see what happen on resize but It's not simple > for me to understand the logic behind. > Currently I'm on IRC (freenode#gnustep nickname: nongio) if anyone would > like to talk about this issue I would appreciate a lot! > > > On 17 December 2013 22:34, Fred Kiefer wrote: > >> You are welcome to look into this. Yesterday I tried to use valgrind >> (callgrind in this case) to detect any anomalies, but couldn't spot any >> big performance change to previous versions. >> >> I also made a quick check and the problem shows up with the cairo and >> the art backend, but not with the xlib one. This points in the direction >> of the shared class XWindowBuffer, but that class no longer gets used by >> the modern cairo implementation in GNUstep. There XGCairoModernSurface >> gets used. >> >> My feeling is that the X server tries to draw the window contents while >> we haven't properly set up the surface to draw it. But this might be >> completely off. >> >> Sorry to be of so little help, >> Fred >> >> On 17.12.2013 10:10, Riccardo Canalicchio wrote: >> > yes, I'm using GNUstep from SVN, someone is already working on this >> > problem? >> > If not, I would like to try to find a solution... Could someone please >> give >> > me some hints to start investigate the problem? >> > >> > On 17 December 2013 07:35, Germán Arias wrote: >> > >> >> Hi, >> >> >> >> I suppose this is with GNUstep from SVN, right? I'm having the same >> >> problem. The window show a black rectangle, that don't fit the window, >> >> while I resize the window. This is not obvious in WindowMaker since, by >> >> default, WM use a "phantom" resize. But if I change this at defaults, I >> >> notice >> >> this problem. However, as far as I remember, the ugly flickering as >> been >> >> there always. >> >> >> >> Germán >> >> >> >> On 2013-12-16 12:38:28 -0600 Riccardo Canalicchio < >> >> riccardo.canalicc...@gmail.com> wrote: >> >> >> >>> hi all, >> >>> I'm experiencing a very annoying bug: during the resize of a window, >> the >> >>> graphic rectangle occupied by the window starts to flicker until the >> >> resize >> >>> is done. >> >>> When I say flicker I mean that the window content is displayed before >> It >> >> is >> >>> completely drawn. >> >>> I'm using the cairo backend. Is this the default behaviour or I missed >> >> some >> >>> configuration steps? >> >> >> ___ >> Discuss-gnustep mailing list >> Discuss-gnustep@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >> > > ___ > Discuss-gnustep mailing list > Discuss-gnustep@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > > ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: flicker graphics on window resize
from my debugging here the call stack of a resize: ... NSWindow _processResizeEvent CairoContext GSSetDevice XGCairoModernSurface initWithDevice XGetWindowAttributes* <-- HERE IS WHERE THE WINDOW BECOME WHITE (OR BLACK) *XGCairoModernSurface.m:48 CairoContext handleExposeRect XGCairoModernSurface handleExposeRect ... and on the next XFlush the window get displayed this mean that XGetWindowAttributes cause an error? On 20 December 2013 17:20, Fred Kiefer wrote: > On 20.12.2013 11:03, Riccardo Canalicchio wrote: > > tell me If I'm right: > > - when using a buffered window there should be two cairo surfaces (back > and > > front) > > - a window resize, trigger the re initialisation of all the two surfaces > > - actually the fresh new surfaces get drawn immediatly (in my case they > are > > white) > > The first two are true according to my understanding. For the third I am > not really sure. We should add some log statements in the class > CairoContext and monitor in which order the following methods get called > during resize and whether the correct surface object gets used: > > + (void) handleExposeRect: (NSRect)rect forDriver: (void *)driver > - (void) GSSetDevice: (void *)device : (int)x : (int)y > > Hope this helps, > Fred > > ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: flicker graphics on window resize
i have asked to the xorg irc channel about the XGetWindowAttributes method, and they have said that: XGetWindowAttributes has to round trip to the server, this mean that has to flush to get the reply containing the results you want from it so the problem is that we have a window without a surface when asking for window attributes On 21 December 2013 13:30, Riccardo Canalicchio < riccardo.canalicc...@gmail.com> wrote: > from my debugging here the call stack of a resize: > ... > NSWindow _processResizeEvent > CairoContext GSSetDevice > XGCairoModernSurface initWithDevice > XGetWindowAttributes* <-- HERE IS WHERE THE WINDOW BECOME WHITE (OR > BLACK) *XGCairoModernSurface.m:48 > CairoContext handleExposeRect > XGCairoModernSurface handleExposeRect > ... > and on the next XFlush the window get displayed > > this mean that XGetWindowAttributes cause an error? > > > On 20 December 2013 17:20, Fred Kiefer wrote: > >> On 20.12.2013 11:03, Riccardo Canalicchio wrote: >> > tell me If I'm right: >> > - when using a buffered window there should be two cairo surfaces (back >> and >> > front) >> > - a window resize, trigger the re initialisation of all the two surfaces >> > - actually the fresh new surfaces get drawn immediatly (in my case they >> are >> > white) >> >> The first two are true according to my understanding. For the third I am >> not really sure. We should add some log statements in the class >> CairoContext and monitor in which order the following methods get called >> during resize and whether the correct surface object gets used: >> >> + (void) handleExposeRect: (NSRect)rect forDriver: (void *)driver >> - (void) GSSetDevice: (void *)device : (int)x : (int)y >> >> Hope this helps, >> Fred >> >> > ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Opinion polls UIKit and Website...
+1 for git On 21 December 2013 22:54, Derek Fawcus < dfawcus+lists-gnustep-disc...@employees.org> wrote: > On Fri, Dec 20, 2013 at 03:05:33pm +, David Chisnall wrote: > > > > If we're moving anything, I'd actually be in favour of Option 3: Move > everything to GitHub. That gives us: > > > > - svn or git views of the repo, so developers can use either > > Agreed. > > Especially if the import is done properly such that the tags and branches > are properly preserved. > .pdf > > ___ > Discuss-gnustep mailing list > Discuss-gnustep@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
theme work in progress
Hi There, I would like to share with you my work in progress theme... I'm working on it from about 2 weeks... the intent of this theme is to make a gui similar to osx maverick. I have choosen to draw things programmatically... I have seen that there is a big work to make the gui themable using images but my intent is to use this theme to study the gnustep internals so I have choose the hard way... the git repository of the theme is here: https://github.com/nongio/rik.theme * the icons are from Meliae GNOME Icon sets developed by Sora: http://sora-meliae.deviantart.com/art/Meliae-SVG-Icon-Theme-v-1-2-151155215 it's probably bugged and not complete at the moment... if anyone would like to help me is welcome! cheers Riccardo ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: theme work in progress
Thanks Fred, for looking at it, my intent is to finish the theme and then discuss with you guys, if some patches are possible and if they makes sense... On 22 December 2013 13:23, Fred Kiefer wrote: > On 22.12.2013 11:29, Riccardo Canalicchio wrote: > > Hi There, > > I would like to share with you my work in progress theme... > > I'm working on it from about 2 weeks... the intent of this theme is to > make > > a gui similar to osx maverick. I have choosen to draw things > > programmatically... I have seen that there is a big work to make the gui > > themable using images but my intent is to use this theme to study the > > gnustep internals so I have choose the hard way... > > the git repository of the theme is here: > > https://github.com/nongio/rik.theme > > * the icons are from Meliae GNOME Icon sets developed by Sora: > > > http://sora-meliae.deviantart.com/art/Meliae-SVG-Icon-Theme-v-1-2-151155215 > > > > it's probably bugged and not complete at the moment... if anyone would > like > > to help me is welcome! > > I looked at the code of this theme and that seems quite nice. It also > shows that we have come a long way with themes, a lot is already > possible but there are still places where theme support in GNUstep is > limited. It should be possible to have themes for window decoration > without actually touching the code of NSWindow and > GSStandardDecorationView. If you have suggestions on how to improve > this, patches are welcome. > > Fred > > > > ___ > Discuss-gnustep mailing list > Discuss-gnustep@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: theme work in progress
thanks David! On 22 December 2013 14:00, David Chisnall wrote: > It looks like a nice start. A few comments: > > - The knob on sliders is drawn slightly too large, so the circle is clipped > yes i know... need to fix this - The scroll bars look a bit ugly - in particular, the buttons are tiny and > difficult to hit. Mind you, scrollers on recent versions of OS X are > pretty hideous too... > yes in the recent osx scroller buttons are gone... > The table view headers and the colour well have not been done yet, I > think. The stepper doesn't seem to have the arrows quite in the centre. > TODO > With the Mac menu bar style, there's still a bug where the menu appears > slightly too low and then jumps to the correct position if you move the > mouse to the top (not the fault of the theme, I think), but aside from that > the menus look very nice. > not finished yet.. > I'd prefer a coloration that gave a bit more visual distinction between > clickable and non-clickable things - the buttons are almost the same colour > as the background, which makes them a bit indistinct. > I will keep this in mind... > I'm looking forward to the final version, > > David > > On 22 Dec 2013, at 12:39, Riccardo Canalicchio < > riccardo.canalicc...@gmail.com> wrote: > > > Thanks Fred, for looking at it, > > my intent is to finish the theme and then discuss with you guys, if some > patches are possible and if they makes sense... > > > > > > > > On 22 December 2013 13:23, Fred Kiefer wrote: > > On 22.12.2013 11:29, Riccardo Canalicchio wrote: > > > Hi There, > > > I would like to share with you my work in progress theme... > > > I'm working on it from about 2 weeks... the intent of this theme is to > make > > > a gui similar to osx maverick. I have choosen to draw things > > > programmatically... I have seen that there is a big work to make the > gui > > > themable using images but my intent is to use this theme to study the > > > gnustep internals so I have choose the hard way... > > > the git repository of the theme is here: > > > https://github.com/nongio/rik.theme > > > * the icons are from Meliae GNOME Icon sets developed by Sora: > > > > http://sora-meliae.deviantart.com/art/Meliae-SVG-Icon-Theme-v-1-2-151155215 > > > > > > it's probably bugged and not complete at the moment... if anyone would > like > > > to help me is welcome! > > > > I looked at the code of this theme and that seems quite nice. It also > > shows that we have come a long way with themes, a lot is already > > possible but there are still places where theme support in GNUstep is > > limited. It should be possible to have themes for window decoration > > without actually touching the code of NSWindow and > > GSStandardDecorationView. If you have suggestions on how to improve > > this, patches are welcome. > > > > Fred > > > > > > > > ___ > > Discuss-gnustep mailing list > > Discuss-gnustep@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > > > > ___ > > Discuss-gnustep mailing list > > Discuss-gnustep@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > > > > > -- Sent from my STANTEC-ZEBRA > > ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
User experience
I think that gnustep has left behind the user experience during this years in favors of portability. In my opinion, users and developers choose cocoa, firstly for the user experience. We need a properly backed drawing for smooth animations and maybe an accelerated window compositor (if GNUstep choose the "we are a desktop" roadmap). What do you think guys about an hardware accelerated drawing? Cairo is great, but is missing some important feature for modern UI. Currently is not possible to do blurs or shadows, animation are slow and I think that this influence the overall experience of GNUstep. I know that is possible to use cairo trough OpenGL but right now is missing all the image filter part.. I have looked at Skia, the graphic library used by google chrome: https://code.google.com/p/skia/ seems very nice and has already implemented most image filter directly on GPU my two cents Riccardo ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: User experience
Thanks David for your response, yes UIKit without Core Animation does not make sense at all... So Opal accelerate only the compositing? it uses cairo on the cpu and then copy the surface on a texture right? anyway yes I would like to help! ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: theme work in progress
Fred, about a patch... I'm working on the NSToolbar, my intent is to integrate the toolbar into the window titlebar like this: https://dl.dropboxusercontent.com/u/3470013/theme/toolbar.png The best would be to draw the titlebar with the height increased by the [toolbarview _heightFromLayout], currently GSTheme expose only one method: titlebarHeight, and seems like the toolbar uses this method to find its position I have made some hacks to make it works but I would like to find a generic solution that could work even if the theme would like a separate nstoolbar.. If this make sense to you, I'm open to suggestions on how could be the right way to do On 22 December 2013 14:12, Riccardo Canalicchio < riccardo.canalicc...@gmail.com> wrote: > thanks David! > > On 22 December 2013 14:00, David Chisnall wrote: > >> It looks like a nice start. A few comments: >> >> - The knob on sliders is drawn slightly too large, so the circle is >> clipped >> > > yes i know... need to fix this > > - The scroll bars look a bit ugly - in particular, the buttons are tiny >> and difficult to hit. Mind you, scrollers on recent versions of OS X are >> pretty hideous too... >> > > yes in the recent osx scroller buttons are gone... > > >> The table view headers and the colour well have not been done yet, I >> think. The stepper doesn't seem to have the arrows quite in the centre. >> > > TODO > > >> With the Mac menu bar style, there's still a bug where the menu appears >> slightly too low and then jumps to the correct position if you move the >> mouse to the top (not the fault of the theme, I think), but aside from that >> the menus look very nice. >> > > not finished yet.. > > >> I'd prefer a coloration that gave a bit more visual distinction between >> clickable and non-clickable things - the buttons are almost the same colour >> as the background, which makes them a bit indistinct. >> > > I will keep this in mind... > > >> I'm looking forward to the final version, >> >> David >> >> On 22 Dec 2013, at 12:39, Riccardo Canalicchio < >> riccardo.canalicc...@gmail.com> wrote: >> >> > Thanks Fred, for looking at it, >> > my intent is to finish the theme and then discuss with you guys, if >> some patches are possible and if they makes sense... >> > >> > >> > >> > On 22 December 2013 13:23, Fred Kiefer wrote: >> > On 22.12.2013 11:29, Riccardo Canalicchio wrote: >> > > Hi There, >> > > I would like to share with you my work in progress theme... >> > > I'm working on it from about 2 weeks... the intent of this theme is >> to make >> > > a gui similar to osx maverick. I have choosen to draw things >> > > programmatically... I have seen that there is a big work to make the >> gui >> > > themable using images but my intent is to use this theme to study the >> > > gnustep internals so I have choose the hard way... >> > > the git repository of the theme is here: >> > > https://github.com/nongio/rik.theme >> > > * the icons are from Meliae GNOME Icon sets developed by Sora: >> > > >> http://sora-meliae.deviantart.com/art/Meliae-SVG-Icon-Theme-v-1-2-151155215 >> > > >> > > it's probably bugged and not complete at the moment... if anyone >> would like >> > > to help me is welcome! >> > >> > I looked at the code of this theme and that seems quite nice. It also >> > shows that we have come a long way with themes, a lot is already >> > possible but there are still places where theme support in GNUstep is >> > limited. It should be possible to have themes for window decoration >> > without actually touching the code of NSWindow and >> > GSStandardDecorationView. If you have suggestions on how to improve >> > this, patches are welcome. >> > >> > Fred >> > >> > >> > >> > ___ >> > Discuss-gnustep mailing list >> > Discuss-gnustep@gnu.org >> > https://lists.gnu.org/mailman/listinfo/discuss-gnustep >> > >> > ___ >> > Discuss-gnustep mailing list >> > Discuss-gnustep@gnu.org >> > https://lists.gnu.org/mailman/listinfo/discuss-gnustep >> >> >> >> >> -- Sent from my STANTEC-ZEBRA >> >> > ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: theme work in progress
My intent is to make the window draggable by the titlebar and the transparent part of the toolbar, i don't want only a bigger drawing but the behavior of a big titlebar. Il 23/dic/2013 13:47 "Fred Kiefer" ha scritto: > On 23.12.2013 10:57, Riccardo Canalicchio wrote: > > Fred, about a patch... > > I'm working on the NSToolbar, my intent is to integrate the toolbar into > > the window titlebar like this: > > https://dl.dropboxusercontent.com/u/3470013/theme/toolbar.png > > The best would be to draw the titlebar with the height increased by the > > [toolbarview _heightFromLayout], > > > > currently GSTheme expose only one method: titlebarHeight, and seems like > > the toolbar uses this method to find its position > > > > I have made some hacks to make it works but I would like to find a > generic > > solution that could work even if the theme would like a separate > nstoolbar.. > > If this make sense to you, I'm open to suggestions on how could be the > > right way to do > > Couldn't you get this effect by just not drawing the separator between > the window decoration and the toolbar when this is present? As far as I > see this is currently not possible, but should be an easy enough change. > > > ___ > Discuss-gnustep mailing list > Discuss-gnustep@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: User experience
Ok, I can help on the shaders field or the frame scheduling ( I'm not really experienced with xorg) the upstream is on svn? I need to study the current code... Do you have any paper of the overall design of CoreAnimation? Currently gnustep seems to have not a roadmap but this project has one? Just another question are you sure to use directly opengl? For example Clutter uses CoGL that wraps opengl and make a common api between opengl and opengles; skia also supports both opengl and gles... i have seen a lot of mails talking about uikit but opengl is not supported on mobile... Il 23/dic/2013 16:33 "Ivan Vučica" ha scritto: > Opal uses Cairo, so it uses whatever acceleration Cairo uses (if any). > > GNUstep's Core Animation implementation that I worked on uses OpenGL. It's > suboptimal right now, but Core Animation is the right way to approach > shadows, blurring et al., as you can use shaders to deal with that. > > Accelerating drawing 2D primitives itself is, as far as I understand, > abandoned by Apple. I may be wrong. There was an implementation of CG that > appeared in 10.5 (I think) that tried to use GL; it was faster in edge > cases, but not generally. > > Again, I may be wrong, but I firmly believe that you want to use Core > Animation if you do animations, compositing, etc., and that it makes no > sense to try to accelerate drawing 2D primitives using 3D cards. > > If you want to contribute to Core Animation, get in touch with me; things > that most sorely need to be worked on are: > - scheduling frames for updates (right now it's a game-style infinite loop > which draws every frame as fast as the GPU can handle it) > - marking 'non-content contents' as dirty, and only updating when the > contents are dirty; for the lack of better term right now, by 'non-content > contents' I mean a 'screenshot' that needs to be taken of the entire > hierarchy to support shadows, filters and perspective-transformed layers. > 'Content contents' on the other hand would be the CGImage or CGContext > assigned to the CALayer > - shadow GLSL shader needs to be properly thought out and implemented, > esp. the blurring > - we need a masking GLSL shader > - CATransition -- a CAAnimation-style object going from one 'contents' > texture to another -- is completely unsupported right now > - dynamic properties need to be generated -- the ones defined > with @interface and not-really-synthesized by @dynamic ; this will clean up > the CALayer code 'a bit' (by which I mean, a lot) > - Core Image-type filters are cute, let's throw that in > > This is approximately in decreasing order of importance (@dynamic thing is > not important at all, but will make code implementing setters and getters a > lot shorter). > > On Sun Dec 22 2013 at 6:10:52 PM, Riccardo Canalicchio < > riccardo.canalicc...@gmail.com> wrote: > >> Thanks David for your response, >> yes UIKit without Core Animation does not make sense at all... >> >> So Opal accelerate only the compositing? it uses cairo on the cpu and >> then copy the surface on a texture right? >> >> anyway yes I would like to help! >> > ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: theme work in progress
hi James, the screenshot is an ubuntu desktop. actually, the window decorations are made by the theme itself On 4 January 2014 21:50, James Carthew wrote: > This looks really really good, is that a Linux screenshot or an OSX > screenshot? If it's Linux, what window manager are you running? > > > On 30 December 2013 01:18, Gregory Casamento wrote: > >> Riccardo, >> >> I just took a look at this and it's a great start. Please keep up the >> good work. I'm excited to see the end result. :) >> >> Greg >> >> >> On Mon, Dec 23, 2013 at 9:09 AM, Riccardo Canalicchio < >> riccardo.canalicc...@gmail.com> wrote: >> >>> My intent is to make the window draggable by the titlebar and the >>> transparent part of the toolbar, i don't want only a bigger drawing but the >>> behavior of a big titlebar. >>> Il 23/dic/2013 13:47 "Fred Kiefer" ha scritto: >>> >>> On 23.12.2013 10:57, Riccardo Canalicchio wrote: >>>> > Fred, about a patch... >>>> > I'm working on the NSToolbar, my intent is to integrate the toolbar >>>> into >>>> > the window titlebar like this: >>>> > https://dl.dropboxusercontent.com/u/3470013/theme/toolbar.png >>>> > The best would be to draw the titlebar with the height increased by >>>> the >>>> > [toolbarview _heightFromLayout], >>>> > >>>> > currently GSTheme expose only one method: titlebarHeight, and seems >>>> like >>>> > the toolbar uses this method to find its position >>>> > >>>> > I have made some hacks to make it works but I would like to find a >>>> generic >>>> > solution that could work even if the theme would like a separate >>>> nstoolbar.. >>>> > If this make sense to you, I'm open to suggestions on how could be the >>>> > right way to do >>>> >>>> Couldn't you get this effect by just not drawing the separator between >>>> the window decoration and the toolbar when this is present? As far as I >>>> see this is currently not possible, but should be an easy enough change. >>>> >>>> >>>> ___ >>>> Discuss-gnustep mailing list >>>> Discuss-gnustep@gnu.org >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >>>> >>> >>> ___ >>> Discuss-gnustep mailing list >>> Discuss-gnustep@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >>> >>> >> >> >> -- >> Gregory Casamento >> Open Logic Corporation, Principal Consultant >> yahoo/skype: greg_casamento, aol: gjcasa >> (240)274-9630 (Cell) >> http://www.gnustep.org >> http://heronsperch.blogspot.com >> >> ___ >> Discuss-gnustep mailing list >> Discuss-gnustep@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >> >> > > ___ > Discuss-gnustep mailing list > Discuss-gnustep@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > > ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
