Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce Basil Info (like Basil Warning, just less dramatic) #91

Closed
trych opened this issue Sep 11, 2016 · 6 comments
Closed

Introduce Basil Info (like Basil Warning, just less dramatic) #91

trych opened this issue Sep 11, 2016 · 6 comments

Comments

@trych
Copy link
Contributor

trych commented Sep 11, 2016

While working on the addToText() method, I realized it might be great to be able to give the user some Feedback about stuff in the console. In the specific case that I'm working on, this might be the info that the text that he just added moved to the "text frame overflow area" (what the heck is the english word for that?). This info might be useful for the user to figure out, why he cannot see the text that he added.

At the moment there is only the possibility to give warnings. Example: in b.units(), there is a warning thrown which writes this statement to the console:

### Basil Warning -> Please note that b.units() will reset the current transformation matrix.

However in the case described above, there is no need to throw a warning (and therefore give the user the impressions that he did something wrong), as the described behavior might be intentional.

TL;DR: Can we introduce a simple Basil Info, which does the same as Basil Warning, but sounds less dramatic and can be used to inform the user about non-dramatic still helpful-to-know stuff?

@ff6347
Copy link
Member

ff6347 commented Sep 12, 2016

If we start to throw infos into the console we need a way to enable/disable them. Println slows down execution.

@ff6347
Copy link
Member

ff6347 commented Sep 12, 2016

Related to #35?

@b-g
Copy link
Member

b-g commented Sep 12, 2016

Yes the flag mentioned in #35 would be good anyways ...

But I'm not very fond to add an info function to the console. It just bothers people in the end and diverts attention from the important console stuff like errors and warnings. Also indesign has built in "warning" mechanisms for "text frame overflow area". I personally don't need this :)

@trych
Copy link
Contributor Author

trych commented Sep 12, 2016

It just bothers people in the end and diverts attention from the important console stuff like errors and warnings. Also indesign has built in "warning" mechanisms for "text frame overflow area".

I was rather thinking about non-obvious cases, where the text already overflows before execution and then there is a word added to the end of the textframe, which immediately moves to the overflow as well. Testing this, it just looks like absolutely nothing happened, and also InDesign will not give any different warnings than before. Hence I thought it would be nice to inform the user in such cases. My plan was not to clutter the console, just to drop an info where it could come in handy.

But if you're both (still) against it, I could also live without it.

@ff6347
Copy link
Member

ff6347 commented Sep 12, 2016

I'm not against giving the user some infos, but it should be opt in not opt out. The problem I see is that if we start giving output to the console it will slow things down. There will be other instances where we also say: "Let's have some output for that!" and then the console gets cluttered. Also b-gs point is also important.

It just bothers people in the end and diverts attention from the important console stuff like errors and warnings.

@trych
Copy link
Contributor Author

trych commented Sep 12, 2016

but it should be opt in not opt out

Hm, I think in this case then the user is more likely to figure out by himself what is wrong, before he gets the idea to set the optional info flag to figure out what's wrong. I'll close this for now, as a dedicated flag for a warning in one place does not make much sense. If we ever find more instances where we see the need to inform the user on stuff, we can reopen this or make a new issue.

@trych trych closed this as completed Sep 12, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants