Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] HTMLPrinter is Broken 
On Wed, Jan 24, 2018 at 3:54 PM, Daniel Megert <daniel_megert@xxxxxxxxxx> wrote:
>> For the record I'm quite unhappy with JDT using so many internals
>
> Come on! JDT is one of those projects using least internals (look at the
> reports). As for the HTMLPrinter JDT registered as friend. Other projects
> can request that too and we will notify them when we plan changes.

The sentence in the original mail continues with good explanation of
why what JDT (UI especially) does in terms of practices influence more
than what is in platform.ua/swt/resourcers - people just don't
reimplement these, while many *DTs start(ed) by direct rip-offs of
JDT.

>
> Dani
>
>
>
> From:        Aleksandar Kurtakov <akurtako@xxxxxxxxxx>
> To:        Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
> Date:        24.01.2018 14:41
> Subject:        Re: [cross-project-issues-dev] HTMLPrinter is Broken
> Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx
> ________________________________
>
>
>
> On Wed, Jan 24, 2018 at 3:30 PM, Ed Merks <ed.merks@xxxxxxxxx> wrote:
>> Comments below.
>>
>>
>> On 24.01.2018 13:38, Aleksandar Kurtakov wrote:
>>>
>>> On Wed, Jan 24, 2018 at 2:27 PM, Ed Merks <ed.merks@xxxxxxxxx> wrote:
>>>>
>>>> I'm a more than little annoyed to see that this method
>>>>
>>>>
>>>>
>>>> org.eclipse.jface.internal.text.html.HTMLPrinter.insertPageProlog(StringBuffer,
>>>> int, RGB, RGB, String)
>>>>
>>>> has gone from deprecated to deleted in less than a 5 week period:
>>>>
>>>>
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse_eclipse.platform.text_commits_master_org.eclipse.jface.text_src_org_eclipse_jface_internal_text_html_HTMLPrinter.java&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=UmJa-cNNUfmKPNGmKf7o2n99HeY0YKXRgqbhf8lBrdM&s=-lnjSbIUTghqgKyroWoJMr17KfHmcyYxhWr4EmgTl_M&e=
>
>>>>
>>>> JDT, EMF, Xtext, and Oomph all use this method.
>>>
>>> So where were the people from these projects all these years and no
>>> one have stepped in to make such a thing proper API?
>>
>> Probably on a cruise ship or tropical island living a happy carefree life
>> with no work.  Of course you could ask the JDT team where they were all
>> these years?  Not on a cruise ship or tropical island I'm sure!
>
> The question included JDT on purpose too. For the record I'm quite
> unhappy with JDT using so many internals from other projects and
> giving bad example to others as many *DT more or less follow what JDT
> does. This in no means make others less guilty of the sin of using
> internals. If people want to have stable and most important
> *supportable* environment the right things should be done even if they
> cause more work now or some issues like porting, ending support for
> old versions and etc. in the transition period. Everything else is
> just wishful thinking IMHO.
>
>>>
>>>
>>>> I really don't care to hear the arguments about it being internal
>>>> because:
>>>>
>>>> I don't see that JDT ought to have exclusive special privileges to use
>>>> internal things.
>>>> I don't see any reason why it should be internal.
>>>> And any client wanting to implement hovers that work like the ones for
>>>> JDT,
>>>> will have the same needs as JDT and will solve the problem the same way.
>>>>
>>>> I'd like to avoid dwelling on the fact that this is simply a pointless
>>>> change, but I can't help it. Surely one wouldn't change this simply to
>>>> improve performance in code that has no relevant performance impact!  It
>>>> seems to me at best a misguided effort that would be better spent on
>>>> real
>>>> improvements.
>>>
>>> Neither you nor me nor anyone else has the right to tell anyone what
>>> to contribute in his own time!
>>
>> No, but I have a right to an opinion.  Although granted I should know
>> better
>> when to keep it to myself.
>>>
>>>
>>>> Please revert this change before M5.
>>>>
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.eclipse.org_bugs_show-5Fbug.cgi-3Fid-3D530240&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=UmJa-cNNUfmKPNGmKf7o2n99HeY0YKXRgqbhf8lBrdM&s=0u0fd2aPJLQvb_EpxjJAyGkBFOVHLcVEpz_OrfS44f4&e=
>>>>
>>>> And in the future, please consider that any internal API that is used by
>>>> any
>>>> other project is going to cause problems for many projects just as it
>>>> did
>>>> for JDT:
>>>>
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.eclipse.org_bugs_show-5Fbug.cgi-3Fid-3D529118&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=UmJa-cNNUfmKPNGmKf7o2n99HeY0YKXRgqbhf8lBrdM&s=wmJYKpCde3jBQIjqd6aF8u5n13f9GY6nXzfgEdvp4XY&e=
>>>
>>> You're not serious, right? Do you seriously expect for every change to
>>> do a check on every Eclipse plugin existing whether it used the
>>> internal method to be changed? Oh wait that can't be only the release
>>> train this must include Pydev, JBoss Tools , Spring Tools and etc,
>>> right?
>>
>> I seriously expect people to be concerned about removing methods. In this
>> case it was clear this impact JDT, so one really didn't need to look far
>> to
>> see the negative impact.
>>>
>>> If anyone has such expectations this is clearly not going to happen.
>>> For every case where someone uses internal he/she must know it's a
>>> risk taken by them on purpose.
>>> I for one strongly disagree with exporting internal packages from
>>> bundles at all, that would solve so many such issues and boost people
>>> to work in proper way!
>>
>> We're all entitled to an opinion.  If they weren't exported, JDT wouldn't
>> have used it, and then it would have been made public, so I suppose there
>> is
>> an argument in favor of that.
>>
>>>
>>>>
>>>> _______________________________________________
>>>> cross-project-issues-dev mailing list
>>>> cross-project-issues-dev@xxxxxxxxxxx
>>>> To change your delivery options, retrieve your password, or unsubscribe
>>>> from
>>>> this list, visit
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=UmJa-cNNUfmKPNGmKf7o2n99HeY0YKXRgqbhf8lBrdM&s=I266QE135eMSa7LwFtSGv838hTvbUQcrlozChUvRiKA&e=
>>>
>>>
>>>
>>
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe
>> from
>> this list, visit
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=UmJa-cNNUfmKPNGmKf7o2n99HeY0YKXRgqbhf8lBrdM&s=I266QE135eMSa7LwFtSGv838hTvbUQcrlozChUvRiKA&e=
>
>
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=UmJa-cNNUfmKPNGmKf7o2n99HeY0YKXRgqbhf8lBrdM&s=I266QE135eMSa7LwFtSGv838hTvbUQcrlozChUvRiKA&e=
>
>
>
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



-- 
Alexander Kurtakov
Red Hat Eclipse Team

Back to the top