On Sat, 6 May 2017 00:48:54 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> because it is PRIVATE to the theme. it may not even present text at > all in any font. you also do not NEED to know. For a font selection dialog you do need to know. Most any font selection dialog I have seen has the current font selected. This is the same for the system Settings -> Font dialog for Custom Font Classes. When you first check that, it does not have the current font selected. > i've explained the > problem of exposing and then not being able to k ow the difference > between choosing font x or default when you do it thw way you want to > do it. to solve it you end up providing a "default" entry in he end > anyway which works the same way without needing to expose. I think your making assumptions about usage and what I am wanting to do. Likely based on elm code and what I am talking about now has NOTHING to do with elm code. Just font handling in general. Also for font selection dialogs. > you have no need to even know. see my prior emails. Yes I do, and this is the behavior of everything else. Again I have NEVER seen a font selection dialog that does not have the current font selected. > you dont NEED to know. Stop assuming that. Even if there isn't a need in your view. > if you knew it was windings and you made > windings selected in a font dialog... how do i explicitly select > windings as opposed to "just give me the default - whatever it is > when it changes"? Not sure what you mean there. I take that as; I like windings. It happens to be the default for the theme. I go to a font selection dialog to set a custom font. When that dialog is activated, Windings is selected because that is the current font for the theme. If the user left it as such. Then Windings gets saved to config file as their custom font. If/when theme font or default changes. That remains as windings per setting saved in config file. Even though it was the same as default. But I suspect your scenario is different than that. > you cannot. you you present the font selector to > the user this way then you cannot have a user select the "just use > the default whatever it is" as you never provide it. you MUST select > a font explicitly. IF you decide that selecting the font that HAPPENS > to be the same as the theme at the time then you CANNOT explicitly > select windings and use that "irrespective of what the theme decides". Yes, if you are saving that value to a config file. > the api is pushing you into a ui design that provides BOTH the > options to the user so the user is able to make that choice. This design makes it MUCH more difficult for developers to give users the proper experience. > you do > not want to present that choice because you want to do it "like > everyone else" and right now refuse to accept that that is the advice > and are insisting on "i must do it like everyone else because there > is one and only one way to do this and they are not doing it the one > and only one way i want". This way EFL is handling fonts in this situation is very sub par. You feel it is superior, and in reality it is inferior. > think about it. i presented the problem. i repeated it again above. > you have no need to know what is inside. Yes, and even the font dialogs in E are wrong. I looked the terminology code. It has a font selected. But it does that by looking up hard coded font names in Terminology to see which is present. Even in Terminology it cannot detect the current font and have that selected in code. It is having to go about it in its own way. Doing that per application is dumb. > i have learned the lesson of exposing too much. the more you expose, > the more you box yourself in and have no freedom to move. we opt for > exposing as little as possible in order to keep the freedom to move. > if it doesn't NEED to be exposed, then don't expose it. What you say is flexibility I see as complete inflexibility from an application development point of view. Having to spent much more time and effort to do things that are trivial else where. Not to mention the share resistance to any change, improvement. Why should people continue spending extra time coding things in EFL they could do in much less time in others? Which given how few things are in EFL. This could be a factor holding back further application development in EFL. > see above. it's incredibly easy to do. add the "default font" entry > as i have suggested multiple times. that or some checkbox hat > disables the font overlay entirely. You are clearly still stuck on elm code or something along those lines and not understanding this clearly. There is no "default font" entry to be added. That is the same as having a check box to disable a custom font. Having that as an entry would BREAK code. Since it would take that font name, and try passing it on. When Fontconfg gets a request for "default font" it will fail. Or require additional code to handle that corner case. Even worse, if by default when that is activated "default font" is selected. But the real font in the list is say Noto Sans. That will be REALLY confusing to the user. Since Noto Sans will not be selected, though its the current font. Instead "default font" would be selected. Which would imply Noto Sans is not the default font when it really is the default font. That makes no sense. In any font dialog the current font should be selected. That is pretty basic, font dialog 101 stuff. > they absolutely do NOT need to know the font being used. Again what desktop env, or OS has a font dialog that does not have the current font selected? This is not how they work. Except for in E. > > I have taken this upstream. > > https://bugs.freedesktop.org/show_bug.cgi?id=100935 > > you know the font may not go via fontconfig at all... ? it just so > happens the default theme HAPPENS to, at this time, want Sans... that > may change tomorrow. you can embed ttf's into edj files and source > them directly from there... this actually worked long before we even > had fontconfig support. That is EVEN worse. Your saying I could put a TTF file, a font for a them into the edj file. Then I have no means to find out what that font name, style, size etc is. That is HORRIBLE!!!! Think about what you just said. That is even worse than the fontconfig handling. At least fontconfig has an idea and you can query it etc. Your saying there is no way to get font information from the theme, edc files etc. That is pretty crazy! > if it's a font from the edj file - the only thing that can access it > is that edje file as it's private data in that edje file for that > edje file only to use... asking for the font used here is > non-sensical as it's embedded in the edj file and otherwise not > generally addressable. Horrible design! Not meant personally though likely will be taken as such. But embedding a font, and providing no means to get information on said font. Are you looking at this from the application development point of view? It is just making things HARDER not EASIER for others. > you lack a lot of depth and breadth of knowledge of efl, I think the world does and there are reasons why it is not being adopted despite its age and history. I cannot emphasize that enough. It is a question I continue to ask myself. Why is there not more stuff written in EFL? Ask your self that. >its > internals, history, design etc. and so you are applying "what i know > from other toolkits" and just assuming it must be the same. it's not. I have coded in a few languages and UI toolkits. This is the first that in ways is a total PITA to code in. From that point of view, back to my question. I can see why there are not many EFL apps. Its a pain to develop them. To different from the rest of the world, etc. > it's different. we were doing a scene graph 10 years or so before qt > cottoned on and then only with qml/qscenegraph and not their regular > widgets. gtk+ is only now beginning to cotton on to the idea of > building your widgets via components and a scene graph. There are tons of obscure tech out there that is superior but will never gain the status, popularity or reach the masses. There are TONS of apps in both GTK and QT, and handful in EFL. Apple is a great example. They always did things different. Where is their desktop market share? They have lost out now to Chrome OS, much less gaining any grounds on Windows. Apple maybe superior in ways. But because of their own non-conformance. They limited them selves. IOS may be far superior to Andriod, but one dominates globally by a vast majority. If it were my lifes work. I would want to see it as widely used as possible. What good does being different be if it just holds you back:? >if we did the > "well let's just be the same as everyone else" game then we wouldn't > get to innovate or do anything interesting. Thats fine and dandy, but you would have a larger community, more applications, more developers. Attract more to the project. Which will bring more innovation, ideas, etc. >we'd always have to wait > for someone else to do it first, it to become "popular an the > expected thing" then copy. I am not even talking about such. Common things, building blocks are missing. Who cares about great innovation when the basics are lacking. > we don't tend to take that path. the > argument of "everyone else does it this way" never ever ever washes > around here. Which means its a niche vs mainstream. > if it's "well this is necessary because otherwise it's > not possible to do x/y/z" then sure. make the argument on its merits, > but not "but everyone else does it". :) and i've explained that you > can achieve what you want (go back to default) without knowing the > font in the theme. presenting it as an ambiguous "sans" option when > selecting it may mean selecting the default or may mean selecting > sans explicitly... is not a better path. There is NO font dialog in E that shows the current font selected. It seems this is impossible due to the superior design of the system.... > the ticket was closed to reflect precisely what the answer is - no. > we're not going to start exposing information that does not need > exposing. it's not rude. it's an answer. Commenting as to why is an answer. Wontfix is a status on a ticket. It is also jumping the gun assuming you know usage. So how does one code a font dialog in E, that shows the current active font selected? That seems impossible. > > Not even a comment just closed wontfix, rather rude! > > https://phab.enlightenment.org/T5453 > > you got commented on the mailing list... Other developers are not going to follow the food chain. They will look at a bug and read its information. I am already providing links to the stuff in mailing list to upstream so they can have an understanding. The more tails they have to chase, places to look for the info. The less likely they will, and harder to get a clear picture. > i've listened, responded, explained etc. i don't think i need to > repeat it. :) stand back a bit and think about it. Yes stand back and think about making apps in EFL. Something I think many have faced and chosen something else. You really need to think about that. Why are there not more things coded in EFL? > just because an > answer is no, does not mean anyone is not open to feedback or > changes. It sure seems that way, and saying WONTFIX is surely not. We are open to ideas and changes to accommodate all. Rather we do it this way. We know better than you. Our stuff is better than all others. Like our way or not. If you do not, your stupid. That is the general vibe given off, and how things are taken. > you need to think about the issue i pointed out before you > start pointing these fingers, because now it's beginning to sound > awfully like "if you don't change how i tell you to change i'm going > to accuse you of being closed minded etc. just to get my way". This is NOT to get my way. Why should I waste time doing things in EFL I can do easily in others? Because of how EFL was designed and refusing to improve that to help with application development etc. This is NOT for me, but for others. But clearly EFL was developed for individuals not others. Since if how it works causes problems for others. Who cares, just figure out how to achieve it via some means. > be > careful of going down that path. it's been explained why exposing is > not needed, how to provide a perfectly decent user interface that > allows the explicit choice of default vs font x and that it will work. Your explaining from one perspective while completing missing and ignoring others. Your thinking elm code, not Font Selection Dialogs. > > It is possible fontconfig will say this is not something that > > pertains to fontconfig. They may blame it on how EFL handles fonts. > > As once again this issue does not exist in GTK, QT, Java, etc. > > it has nothing to do with fontconfig at all. Previous posts were saying that. Also when you are requesting Sans, and not a specific sans. You are leaving that up to fontconfig. Unless the theme has a font embeded. Which I have not seen. How many unique themes for E exist? Any I have seen thus far all use the default. Theming E seems like some black art very few know about. Thus next to no themes exist. > > Yet another example, wxwidgets > > > > wxSYS_SYSTEM_FONT System font. > > > > By default, the system uses the system font to draw menus, dialog > > box controls, and text. > > http://docs.wxwidgets.org/trunk/settings_8h.html#ac542cdc9950a6cf3b7a42f7e77ada05b > > > > You can retrieve the current system font settings with > > wxSystemSettings. > > http://docs.wxwidgets.org/trunk/classwx_font.html > > not going to wash with just "but everyone does this". a cogent > argument is closer to the one you presented: It is not about conformance. It is about developers having easy access to standard routine fundamentals. There is a reason all are doing this in their own ways. Not a single example had the same code/usage, etc. They were all different. But they all provide means to get information on fonts. Which is something to make it easier on application developers. >"i need to display what > is currently the state of things in a dialog to select fonts" ... and > you mistake that current state for it being "sans" or "monospace" or > "windings"... the current state is "default font" Even the global font settings dialog, Custom Font Class, does not have a default font entry.... I have NEVER seen a font dialog box that had a "Default font" entry. They simply have the default current font selected. > ... whatever that > maps to can change at any point. if you construe "sans" to ALSO mean > "default" just because current theme uses sans... hen you rob the > user of the choice of choosing sans. Not really. Your taking that the wrong way. The user could still set Sans. Even though its the default. I consider that a safety fall back. I like Sans. I want to ensure my font remains sans if the theme font changes. > if you construe the other way > (that it means sans ans always sans" then you never give the user the > option of "just let the system/theme decide". you are giving 1 entry > in the list 2 possible meanings. my advice is to have 2 entries. 1 is > sans. one is "default font" and user explicitly selects. Users are robbed of such options and controls now. It is very difficult from an application development perspective to give such to a user. Of the EFL apps that do exist? How many have font selection dialogs? I bet none are selecting the current font, etc. See the forest through the trees or not. Such difficulties can be the deciding factor for someone coding an app in EFL or some other. Why despite EFL being superior, most stuff is written using other things. It can remain that way or change. That is up to you all not me. I can chose to use other stuff, like most have. -- William L. Thomson Jr.
pgpP7VECMayNg.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
