Skip to main content ↑ ↓
Topic: Re: attachmentz (Read 16560 times) previous topic - next topic - Topic derived from attachmentz
0 Members and 1 Guest are viewing this topic.

Re: Re: attachmentz

Reply #15 –

Then that's a bug! :P
As a workaround, I'd suggest to set the visualization as "discussion", that will let you access it. ;)
Bugs creator.
Features destroyer.
Template killer.

Re: attachmentz

Reply #16 –

QuotePlease refer to the 2 screen shots attached, one of my inbox and other of my settings. I must be missing something really bad.
Yup a bug it is !  Gosh darn, have I mentioned how much I hate that section of code :

QuoteAlso ema has bought this into my notice that elkarte is supporting minimum PHP version 5.1, so to make drag drop work properly we can port the json function from '
Indeed 5.1 (5.1.2 to be specific) ... for sure we could port that function over, I think it would be useful for addon writers, so perhaps it can be added in Subs.php as a support function.  Thats what we did with an array slicer function to help people inject new items in the the menus. 


ETA: one other thing ... in those screen shots I noticed the search drop down box is small compared to the input and select button on either side of it.  If you get a moment could you debug that?  I don't have access to Mac stuff so can't do that myself :(

Last Edit: January 26, 2014, 10:54:11 am by Spuds

Re: Re: attachmentz

Reply #17 –

Quote from: Spuds – ETA: one other thing ... in those screen shots I noticed the search drop down box is small compared to the input and select button on either side of it.  If you get a moment could you debug that?  I don't have access to Mac stuff so can't do that myself :(

OSX forces its own style on select boxes. I think you need to use something like -webkit-appearance: none; for the select boxes you are styling. Also, use of semi-bold fonts (the family) part for key areas (as you define it) doesn't seem to be working well for me. Attached a screenshot for that.

Re: attachmentz

Reply #18 –

Quote from: [SiNaN] – OSX forces its own style on select boxes. I think you need to use something like -webkit-appearance: none; for the select boxes you are styling
Good to know, thanks.
Quote from: [SiNaN. Also, use of semi-bold fonts (the family) part for key areas (as you define it) doesn't seem to be working well for me. Attached a screenshot for that.
Is that OSx as well or other? Looks like plain old bold in those pics which is the fallback state if its unable to find the demi font face.    I know it will not work on *nix at this point and of course it will do that if it can't find the demi bold face on any OS.   Windows uses Segoe UI,.  OSx should use Helvetica Neue.

Messing with these font faces is just ugly and the only way I know to address is font-face, like this but with a 600 weight and use Open Sans for those areas (all go all out and use it everywhere) ... downside, its not local, upside its probably already in your cache.
Code: [Select]
@font-face {
  font-family: "Open Sans";
  font-style: normal;
  font-weight: 400;
  src: local('Open Sans'), local('OpenSans'), url(http://themes.googleusercontent.com/static/fonts/opensans/v7/cJZKeOuBrn4kERxqtaUH3T8E0i7KZn-EPnyo3HZu7kw.woff) format('woff');
}

Re: Re: attachmentz

Reply #19 –

Yep, that's OSX too.

Re: Re: attachmentz

Reply #20 –

This should be the family, so the question is do any of them have a 600 weight font, or even a bold that render demi. 

Right now of OSx the 600 weight should be calling Helvetica Neue Medium, maybe that needs to be bold with that face to be demi (fonts are weird).   If not do any of the family provide a nice 600 semi-demi-almost-bold look?

Helvetica Neue
Helvetica Neue Bold
Helvetica Neue Italic
Helvetica Neue Bold Italic
Helvetica Neue Condensed Bold
Helvetica Neue UltraLight
 Helvetica Neue UltraLight Italic
Helvetica Neue Light
Helvetica Neue Light Italic
Helvetica Neue Condensed Black
Helvetica Neue Medium
Helvetica Neue Medium Italic
Helvetica Neue Thin
Helvetica Neue Thin Italic

Any help is appreciated !

Re: Re: attachmentz

Reply #21 –

Sure. I have tried most of those but anything other than "Helvetica Neue" is not recognized at all. I think I have a fairly regular setup (OSX 10.8.5) and I'm using Chrome (32.0.1700.77). I'm not sure how it's supposed to look, so I'm attaching some screenshots. Let me know if there's anything else I can do to help with this one.

Re: attachmentz

Reply #22 –

Thank you for those images, that does help.

It looks like the current one does have less "weight:" to the bold font, just not as much as what I see under windows.  

Reading a bit on the web it appears that adding -webkit-font-smoothing: antialiased; to the demi declaration may help de-emphasize it a bit further so I may add that to the css to see if it helps.

Re: Re: attachmentz

Reply #23 –

Attached a screenshot with that one added. It looks better and might really be might you're after.

Re: attachmentz

Reply #24 –

That is looking better, thanks for testing, the change will be in the next update.

The idea was in select areas bold had to much visual punch, so a gentler one was wanted.  That lead to the 600 weight being added some time ago with some known limitations in certain combinations.   Over time we kept finding more combinations that did not work, seems that's always the way.  Now I think we are back to having more, combinations work as expected.

Re: attachmentz

Reply #25 –

Apologies for not able to reply to the topic early.

Guys to check out the PR 8).

On my todo list for drag drop attachments:
- Pass language strings to javascript from php to remove hardcoded text strings
- Make all sorts of check like file extensions, file size etc in 'Attachment.controller.php' 'action_ulattach'

All suggestions, advices, rants, scoldings are most welcomed.

Coming back to dropdown issue as pointed out by @Spuds
- I've working very closely with iOS and OSX(in job) and what I've observed over the years is if one uses the font size in even numbers, the fonts are rendered more smoothly and crisp. I'll try to see all the test forum pages on mac and come out with solutions for UI etc.

Happzzz codingzz :D

Re: Re: attachmentz

Reply #26 –

You should avoid using die(). You should set the templates/layers to empty and then let the script finish executing. Also, maybe add some hooks in there? I can definitely see someone wanting to change where these attachments go and how they get processed. Just suggestions though, because if it works, add it.

Re: Re: attachmentz

Reply #27 –

Quote from: groundup – You should avoid using die(). You should set the templates/layers to empty and then let the script finish executing.
Like XML templates?
- we would be calling a function
- settings values in a global array
- echoing the data from template layer

By the way whats any specific reason of not using die except that it terminates the script on my terms :-X ?

Quote from: groundup – Also, maybe add some hooks in there?
Ummm, please elaborate.

Re: Re: attachmentz

Reply #28 –

That's the point - it's on your terms, not on the whole application's terms. There might be things that need to happen after that. Just saying it is generally regarded as not good programming practices.

I can see a want to have attachment uploads do something different when uploaded via AJAX. Maybe add a "integration" hook in there to allow pre and post processing. What if someone wants to change the result or make the data different.

Re: Re: attachmentz

Reply #29 –

Progress
- Attachments uploaded in a queue, as earlier if someone dropped multiple attachments only the last one was added
- Removed die() and utilised template layers via Json.template.php
- Placed checks for session
- Checks in JS to account if any file is already attached/size etc while modifying a post
- Bug fixes for regex and minor tweaks

Also for passing language strings from PHP to JS can we use something like this?